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

Re: [bluetooth-dev] Stack design and some anoucements

Hi all,

I've recently started thinking about bluetooth stack design as well. My
ideas were quite close to what Max proposes here. I have some comments
to make though:

>         L2CAP sockets:
>                 Supports all standard socket stuff: connect, bind, listen, accept, read, write, etc
>                 Seqpacket socket type for connection oriented channels
>                 Raw socket type for sending/receiving signalling messages
Why not use the socket interface as just another upper layer for L2CAP
as for example RFCOMM. If one needs the socket interface, they load it,
if they want to use directly RFCOMM, they can do that. This would be the
same case one can think of as upper layers for RFCOMM itself. One is the
port emulation and the other the port proxy (which itself might be the
line discipline of another serial port).

>         Multi threaded frame processing:
>                 Inherently multi threaded by HCI core
What is much nicer than in the axis stack is "bottom half"-like
processing. Decoupling interrupts from frame processing.

>         L2CAP features:
>                 Up to 64K L2CAP mtu (fragmentation / reassemble)
>                 Unlimited number of channels per connection
Don't go you a little bit high there on the number of channels? ;-)

> Stack was designed for 2.4.x kernel (back port should possible thou).
As far as the back port is concerned, one issue of course are the
tasklets. They may be implemented using task_queues instead, but I've
just read that the tasklets were more future proof.

I thing I haven't found is the security manager or a corresponding

I think the library mentionned in another post is the most important.
There has to be a nice and easy to use library for everyone. A stack all
by itself is not of any use, is it?

Another issue to keep the stack small might be to make it configurable.
Why not introduce options like client-only, server-only, minimal,
maximal, no authentication etc.? If these categories are well defined,
one could save a lot of memory.


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