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 would like to find a simple approach for now and maybe we can consider more complex restructuring later on for the host layer if necessary. Best, Matias On Mon, Aug 24, 2020, at 00:32, Brennan Ashton wrote: > Personally I think the abstraction is in the wrong place. In most systems > including Linux you provide HCI, L2CAP and RFCOMM sockets from the kernel, > then all the GATT and connection management logic is moved into a daemon > that runs in user space. Some devices do not exposed HCI so the kernel > implements a virtual HCI inteface. > This is going to make things like Bluetooth mesh even harder to implement. > > This is also the abstraction that's Zephyr also mostly take. With the > exception of the case where it is implementing the controller. In that case > it still exports the HCI interface. > > https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-arch.html > > --Brennan > > > On Sun, Aug 23, 2020, 8:16 PM Matias N. <mat...@imap.cc> wrote: > > > Hi, > > > > I'm continuing work on BLE on the NRF52832 and I would like to instantiate > > a GATT server (to eventually provide HID over GATT for providing a > > bluetooth mouse). Looking at the upper layers of BLE in NuttX you can see > > that it ends up in a network devices which exposes different functionality > > via IOCTL calls. While there are calls to access GATT attributes as a > > client (discovering, reading, writing, etc. to a remote GATT server), > > there's no interface for instantiating a server. > > > > Looking at bt_gatt.h, there are definitions which can be used to register > > a table of characteristics using bt_gatt_register() call. Now, this table > > holds pointers to callback functions which are invoked to retrieve the > > value of each characteristic, as it is requested by the remote client. This > > means that if I were to expose this bt_gatt_register() function via an > > IOCTL call (receiving a pointer to the table), the networking layer would > > be calling into a userspace function. As this is undesireable I'm thinking > > what would be the best way to support this. > > > > An alternative would be to skip the network layer completely, writing a > > device driver representing the mouse itself and have that driver interact > > with bt_* functions. This way, all of this is at OS level. However, there's > > a lot of functionality on the bt_netdev level which I would be losing and > > I'm not sure if it is supposed to be used like this (ie, having something > > in parallel to the network layer accessing BLE from a driver). > > > > Anyone with knowledge of BLE have any hints? I don't know how for example > > Linux decouples this. > > > > Best, > > Matias >
