[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Stack design and some anoucements
> >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 ?
I was thinking about an interface similar to what you have done with
HCI. An interface that can be registered besides the socket interface.
This could be useful if you don't have enough space for all the socket
interface (in this case you had to have a possibility to replace sk_bufs
I guess, or make them dependent on the stack) and you don't require it.
This could be the case if you use OBEX over RFCOMM for example.
> 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.
If you have to/want to use sockets I agree. It is a clean solution. I've
been thinking of a stack as flexible as possible (and I understand under
stack more or less what is specified by the spec). For some reason I
don't really like the idea to cut the whole stack in half (just a design
question, performance should be more or less the same).
> >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'll have to look a little more through your code first. I've mostly
looked at the general design and the interfaces.
> >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.
By library I mean nice functions to invoke inquiry, paging and the like.
> >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.
What I meant here applies more to upper layers. Also functions in L2CAP
like connect_ind and connect_rsp are not required for a client
application, for example.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com