[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Relationship between components



Matthew Palmer wrote:

> Hmm.  I've had a quick scan - what would be the practicality of developing a
> library which implemented the setup, inquiry, and connection functions.
>

If it could be done it might be very practical. It is a pain in the ass to have to
start another app just to start the one you really want. But the issue is letting
multiple apps use bluetooth at the same time. The two scenarios in effect right now
are:
1. A btd-like 'manager' app sets up the physical connection and leaves it open.
Other apps come along and compete with each other for RFCOMM channels (and an
SCO channel, when that sorts itself out). And somehow SDP needs to get involved to
keep track of which apps have which channels, right? You SDP folks can help me out
here. Note that this is the solution IrDA uses.
2. Or, each app sets up the connection itself, thus one app can use the stack at a
time. Not cool.

> and possibly moving portions of the stack out of kernel space?  At a
> guess, I'd say that L2CAP would probably be best left in the kernel, but
> surely the layers above don't need kernel features?
>

RFCOMM must remain in the kernel because it must implement a tty driver. This is per
the spec and, sure enough, ppp needs it.

SDP can probably move out, and the SCO users will almost definitely be out. The
problems then is one of providing an interface to L2CAP for them to use. I'll spare
you all my rant on that subject, but you can probably find portions of it in the
archive.

> Ah, that's a help.  So if I execute btd with appropriate commands to make
> several connections, I can then talk on /dev/ttyBT{0..n} (for n < 7, at
> least on my install) via ordinary everyday serial functions.
>

That's the idea. I don't know if anyone has suceeded there or not. Someone was
trying to make minicom work...

While we're on the subject I'll throw in my two cents concerning architecture. IrDA
is probably more like Bluetooth than anything else in terms of the variety of
protocols and interfaces. In most cases you can find an analog for any Bluetooth
protocol layer or interface (IrCOMM = RFCOMM, IAS = SDP, IrLAP = basband, IrLMP =
L2CAP, etc). The combination of specified interfaces and where they branch in and
land on the protocol stack is similar and, I think, very very weird in a 'datalink
layer'.

So I propose that people who are interested in developing/improving the stack take a
look at how IrDA was done. To sum up, they implement a network interface on top of a
tty which controls the hardware link, and this is the rock bottom of the stack.
IrLAP sits on top of that, and everything else stacks on IrLAP.

In the case of Bluetooth, by analogy, the underbelly of HCI could provide the
network interface. In other words, HCI-USB or HCI-UART would be a tty which
registered a network interface to the kernel. The generic HCI and friends would
stack above that and do whatever. I may have blundered some details here, but if
you're interested go look for yourself.

--gmcnutt

-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com