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

Re: [bluetooth-dev] Relationship between components

Le Mardi 13 Février 2001 03:20, vous avez écrit :
> 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.

I wouldn't say RFCOM "must" run in kernel mode... We are running the stack in 
user mode and RFCOMM opens a pty device, and pppd runs on top of it with no 
problem. It is possible though that the performance is better if the rfcomm 
serial ports run in kernel mode (but this should be checked...).

> 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...

We never tried that because we have never been able to have the stack run in 
kernel mode (kernel 2.4.0), but sure that the plain old pppd runs on 
/dev/ptyxn exactly as on a serial port.

> 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
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com