You're right, maybe I'm caught on the callback interface because that is how it is implemented now, but in the end there's always a packet you process. I still wonder if also having L2CAP in kernel would be better since it deals with multiple connection handling, packet fragmentation and so on (to me it is like TCP, but maybe I'm reading it wrong).
Anyway, as I'm still finishing the link layer and I wouldn't want to get into this before completing that. But it would be cool if you or someone else would be willing to look into this further, I could then contribute to that effort. I guess I will hack something locally to make a GATT server until we devise a clean way to do it. Best, Matias On Mon, Aug 24, 2020, at 01:06, Brennan Ashton wrote: > On Sun, Aug 23, 2020, 8:45 PM Matias N. <mat...@imap.cc> wrote: > > > Hi Brennan, > > > > Yes, as I understand the host layer is actually from (early?) Zephyr code. > > > > The way you suggest it should be done sounds very reasonable. However I > > wonder if this is > > always the right approach. Right now the HCI layer is using work queues to > > handle > > communication with different priorities. So I would guess that it would be > > best to expose at > > L2CAP level. From the looks of it, GATT is more like a library with > > convenience functions, but > > there are still many callbacks so the problem would be the same as now I > > think. Are callbacks > > abstracted via read/write on sockets in this case? Or what would be the > > simplest way to > > handle callbacks from OS to application? I can only think of POSIX > > signals, but that feels quite > > limited. > > > I'm not sure I follow. Normally the kennel would expose the HCI socket and > the you would issue a read on the socket to identify events to act on. That > would include an action like reading a GATT entry. With bluez there is a > user space daemon that does just that and then applications register via > dbus. Here it would probably be less important to have the daemon since > would likely only have a single application doing Bluetooth so you could > just make the GATT a library. > > The Bluez daemon also makes use of file descriptors for managing events if > you want to use that instead of the dbus API. So I suppose that could be > used here as well I just don't see why we have GATT in the kernel. That > seems like the wrong thing. > > > BlueZ is also doing some things to handle some HCI events in the kernel you > can fully unregister the device from connection management by requesting a > BTUSER_CHAN which Zypher once again also supports in POSIX mode. > > Reinventing this abstraction is probably not in our best interest. > > > --Brennan > > > >
