On Mon, Aug 24, 2020 at 2:25 PM Gregory Nutt <spudan...@gmail.com> wrote: > > >>> I have been puzzling through the Goobledegook GATT server (GGK, > >>> https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus > >>> interface. It is GPLv3 so not a candidate for porting. And also not > >>> much use for understanding APIs since the OS interface is hidden inside > >>> of the Bluez D-Bus interface > >>> (https://core.docs.ubuntu.com/en/stacks/bluetooth/bluez/docs/reference/dbus-api) > > Yeah I am very familiar with this having shipped devices on top of the > > dbus API. The dbus API is provided by bluetoothd which intern is > > using the kernel socket interface. Goobledegook is not really > > providing us anything here since the underlying bindings between > > sockets and GATT are still in bluetoothd. > So would adding the appropriate socket types and ioctls then > re-implementing the d-bus API make a reasonable portability layer? That > could be a pretty well defined job.
You are going to hate dbus :) Honestly it is designed to be a system wide message bus for desktop/server software and defines even a wire message format that supports things like introspection. I think that is wrong for a small embedded system. That leaves the question of what should be used for IPC for the GATT server daemon. I suspect we could get far using event file descriptors, but also just having a library where a single application owns the GATT server is probably fine. The dbus service is nice because I can write a standalone application that provides the BAT service for showing battery life, and then have another application that broadcasts RPMs from a cadence sensor. --Brennan
