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

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


>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. 
What do you mean by direct interface ? 
In BlueZ socket is the only direct interface to L2CAP which can be used in user and kernel spaces. There is nothing more direct than that :)).
Socket == L2CAP channel. Why would you want to implement some other structures, lists, etc if you can keep all info in socket itself 
and that's what BlueZ L2CAP layer does. It is clearly more efficient to maintain one unified entity like socket that already has one unified 
interface, than invent some other interface and then emulate sockets on top of it. 

> >         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 ? ;-)
Nop :))

> > 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.
Ohh yes, Tasklets are much better and much more efficient. If back port will be necessary 
something similar(not really :)) could be implemented using Taskqueues. 

>I thing I haven't found is the security manager or a corresponding
That's up to hcid. But you right it is not implemented yet. Would you be interested ?

>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 ?
Actually L2CAP sockets by themselves provide all necessary functionality for L2CAP apps.
But you right library is also important.

>Another issue to keep the stack small might be to make it configurable.
It is :)). If you don't need USB or UART don't load the driver. If you don't need L2CAP don't load L2CAP module.
App can switch device to RAW mode and HCI core won't even do event processing. So, I think it is pretty configurable
right now.

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

Server-only and client-only will save you only one socket function in each case accept - in case of the client only, 
connect - in case of the server only. As you can guess this functions are about 10-20 lines of C code. Everything else 
is pretty much the same. 
Well, actually you could through out some other connection handling stuff but is it no worth it.


Maksim Krasnyanskiy		
Senior Kernel Engineer
Qualcomm Incorporated

(408) 557-1092

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