[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Stack design and some anoucements
> > 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.
That's the thing. You'll have to "invent" some new interface for the protocol that is perfectly suited for the socket api.
I agree that one may develop "smaller" api for L2CAP that sockets but sockets are not at all that expensive in terms
of resources. You may save 1-10K but you'll most likely lose compatibility, efficiency, etc.
BTW Sockets are _always_ present in the kernel (unless you hack it really hard :)). Look in the init/main.c, they are
initialized unconditionally, which make sense because even pipes are implemented using sockets :).
So, the point is I don't think that you'll save a lot by "inventing" other non-standard api.
>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).
What do you mean by "cut the whole stack by half" ?
> > 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.
Paging is initiated by calling connect on L2CAP socket.
Inquiry should be in the library.
Senior Kernel Engineer
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org