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 >
