* Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? @ 2016-03-02 13:20 Olivier Martin 2016-03-02 14:18 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 5+ messages in thread From: Olivier Martin @ 2016-03-02 13:20 UTC (permalink / raw) To: linux-bluetooth Hello all, I am looking at writing a new GATT (server) service for my Linux-based bluetooth device using Bluez. My device use Debian stable (Jessie) that uses Bluez v5.23. Ideally, I would like to build my GATT service out of the Bluez tree. As far as I understand I have two solutions: Solution A) Stay with Bluez v5.23 and write a plugin. I managed to build `plugins/gatt-example.c` out of the tree. But when `bluetoothd` loads the plugin, it fails to find the symbol `attrib_db_update`. I am wondering if it is due to the fact `shared/gatt-server` has not been added to v5.23 (https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/shared?h=5.23). And in this case it would not be possible to have a GATT service out of the tree for this Bluez version. Solution B) Moving to the latest Bluez version and use the GATT server D-BUS API. But it means I need to remove and replace Bluez on my stable Debian. I understand this solution is the long term solution but it might take a while before the Linux distributions used this version of Bluez. So, is it possible to have an out of the tree plugin with v5.23? I saw `sixaxis` plugin. But this plugin does not manipulate GATT services and characteristics. Thanks, Olivier ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? 2016-03-02 13:20 Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? Olivier Martin @ 2016-03-02 14:18 ` Luiz Augusto von Dentz 2016-03-02 14:34 ` Szymon Janc 2016-03-02 14:35 ` Olivier Martin 0 siblings, 2 replies; 5+ messages in thread From: Luiz Augusto von Dentz @ 2016-03-02 14:18 UTC (permalink / raw) To: Olivier Martin; +Cc: linux-bluetooth@vger.kernel.org Hi Olivier, On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin <olivier.martin.fr@gmail.com> wrote: > Hello all, > I am looking at writing a new GATT (server) service for my Linux-based > bluetooth device using Bluez. > My device use Debian stable (Jessie) that uses Bluez v5.23. > Ideally, I would like to build my GATT service out of the Bluez tree. > As far as I understand I have two solutions: > > Solution A) Stay with Bluez v5.23 and write a plugin. I managed to > build `plugins/gatt-example.c` out of the tree. But when `bluetoothd` > loads the plugin, it fails to find the symbol `attrib_db_update`. I am > wondering if it is due to the fact `shared/gatt-server` has not been > added to v5.23 (https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/shared?h=5.23). > And in this case it would not be possible to have a GATT service out > of the tree for this Bluez version. It depends on the level of control you want to have, if you need extra permissions and low level of access than perhaps building as a plugin is probably a good idea. BlueZ daemon works kind similar to the kernel, the internal API may change so building out of the tree will never be very stable, and you still have to comply to GPL. > Solution B) Moving to the latest Bluez version and use the GATT server > D-BUS API. But it means I need to remove and replace Bluez on my > stable Debian. I understand this solution is the long term solution > but it might take a while before the Linux distributions used this > version of Bluez. If more people like you starting using this features it might become stable faster, thus we encourage people to go with this solution. Btw, you can disable the BlueZ from your distro and just run BlueZ from source without overwriting anything from your distro. > So, is it possible to have an out of the tree plugin with v5.23? I saw > `sixaxis` plugin. But this plugin does not manipulate GATT services > and characteristics. Possible, yes, but it is not recommended, but you can try to create a external plugin that is build within the source tree so that we keep it working as we change the internal APIs. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? 2016-03-02 14:18 ` Luiz Augusto von Dentz @ 2016-03-02 14:34 ` Szymon Janc 2016-03-02 14:42 ` Olivier Martin 2016-03-02 14:35 ` Olivier Martin 1 sibling, 1 reply; 5+ messages in thread From: Szymon Janc @ 2016-03-02 14:34 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Olivier Martin, linux-bluetooth@vger.kernel.org Hi, On Wednesday 02 of March 2016 16:18:22 Luiz Augusto von Dentz wrote: > Hi Olivier, > > On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin > > <olivier.martin.fr@gmail.com> wrote: > > Hello all, > > I am looking at writing a new GATT (server) service for my Linux-based > > bluetooth device using Bluez. > > My device use Debian stable (Jessie) that uses Bluez v5.23. > > Ideally, I would like to build my GATT service out of the Bluez tree. > > As far as I understand I have two solutions: > > > > Solution A) Stay with Bluez v5.23 and write a plugin. I managed to > > build `plugins/gatt-example.c` out of the tree. But when `bluetoothd` > > loads the plugin, it fails to find the symbol `attrib_db_update`. I am > > wondering if it is due to the fact `shared/gatt-server` has not been > > added to v5.23 > > (https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/shared?h=5.23). > > And in this case it would not be possible to have a GATT service out of > > the tree for this Bluez version. > > It depends on the level of control you want to have, if you need extra > permissions and low level of access than perhaps building as a plugin > is probably a good idea. BlueZ daemon works kind similar to the > kernel, the internal API may change so building out of the tree will > never be very stable, and you still have to comply to GPL. > > > Solution B) Moving to the latest Bluez version and use the GATT server > > D-BUS API. But it means I need to remove and replace Bluez on my > > stable Debian. I understand this solution is the long term solution > > but it might take a while before the Linux distributions used this > > version of Bluez. > > If more people like you starting using this features it might become > stable faster, thus we encourage people to go with this solution. Btw, > you can disable the BlueZ from your distro and just run BlueZ from > source without overwriting anything from your distro. > > > So, is it possible to have an out of the tree plugin with v5.23? I saw > > `sixaxis` plugin. But this plugin does not manipulate GATT services > > and characteristics. > > Possible, yes, but it is not recommended, but you can try to create a > external plugin that is build within the source tree so that we keep > it working as we change the internal APIs. External plugins (like sixaxis) are able to use only btd_* (plus few exceptions) functions. If you want to use other symbols you would have to go with builtin plugin. -- BR Szymon Janc ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? 2016-03-02 14:34 ` Szymon Janc @ 2016-03-02 14:42 ` Olivier Martin 0 siblings, 0 replies; 5+ messages in thread From: Olivier Martin @ 2016-03-02 14:42 UTC (permalink / raw) To: Szymon Janc; +Cc: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org Thanks Szymon that is the limitation I was suspecting about. After having a quick look to the btd_* functions, it looks to be unlikely I can register a GATT server service with an external plugin. On 2 March 2016 at 14:34, Szymon Janc <ext.szymon.janc@tieto.com> wrote: > Hi, > > On Wednesday 02 of March 2016 16:18:22 Luiz Augusto von Dentz wrote: >> Hi Olivier, >> >> On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin >> >> <olivier.martin.fr@gmail.com> wrote: >> > Hello all, >> > I am looking at writing a new GATT (server) service for my Linux-based >> > bluetooth device using Bluez. >> > My device use Debian stable (Jessie) that uses Bluez v5.23. >> > Ideally, I would like to build my GATT service out of the Bluez tree. >> > As far as I understand I have two solutions: >> > >> > Solution A) Stay with Bluez v5.23 and write a plugin. I managed to >> > build `plugins/gatt-example.c` out of the tree. But when `bluetoothd` >> > loads the plugin, it fails to find the symbol `attrib_db_update`. I am >> > wondering if it is due to the fact `shared/gatt-server` has not been >> > added to v5.23 >> > (https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/shared?h=5.23). >> > And in this case it would not be possible to have a GATT service out of >> > the tree for this Bluez version. >> >> It depends on the level of control you want to have, if you need extra >> permissions and low level of access than perhaps building as a plugin >> is probably a good idea. BlueZ daemon works kind similar to the >> kernel, the internal API may change so building out of the tree will >> never be very stable, and you still have to comply to GPL. >> >> > Solution B) Moving to the latest Bluez version and use the GATT server >> > D-BUS API. But it means I need to remove and replace Bluez on my >> > stable Debian. I understand this solution is the long term solution >> > but it might take a while before the Linux distributions used this >> > version of Bluez. >> >> If more people like you starting using this features it might become >> stable faster, thus we encourage people to go with this solution. Btw, >> you can disable the BlueZ from your distro and just run BlueZ from >> source without overwriting anything from your distro. >> >> > So, is it possible to have an out of the tree plugin with v5.23? I saw >> > `sixaxis` plugin. But this plugin does not manipulate GATT services >> > and characteristics. >> >> Possible, yes, but it is not recommended, but you can try to create a >> external plugin that is build within the source tree so that we keep >> it working as we change the internal APIs. > > External plugins (like sixaxis) are able to use only btd_* (plus few > exceptions) functions. If you want to use other symbols you would have > to go with builtin plugin. > > -- > BR > Szymon Janc ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? 2016-03-02 14:18 ` Luiz Augusto von Dentz 2016-03-02 14:34 ` Szymon Janc @ 2016-03-02 14:35 ` Olivier Martin 1 sibling, 0 replies; 5+ messages in thread From: Olivier Martin @ 2016-03-02 14:35 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org Thanks Luiz for your answer! On 2 March 2016 at 14:18, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Olivier, > > On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin > <olivier.martin.fr@gmail.com> wrote: >> Hello all, >> I am looking at writing a new GATT (server) service for my Linux-based >> bluetooth device using Bluez. >> My device use Debian stable (Jessie) that uses Bluez v5.23. >> Ideally, I would like to build my GATT service out of the Bluez tree. >> As far as I understand I have two solutions: >> >> Solution A) Stay with Bluez v5.23 and write a plugin. I managed to >> build `plugins/gatt-example.c` out of the tree. But when `bluetoothd` >> loads the plugin, it fails to find the symbol `attrib_db_update`. I am >> wondering if it is due to the fact `shared/gatt-server` has not been >> added to v5.23 (https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/shared?h=5.23). >> And in this case it would not be possible to have a GATT service out >> of the tree for this Bluez version. > > It depends on the level of control you want to have, if you need extra > permissions and low level of access than perhaps building as a plugin > is probably a good idea. BlueZ daemon works kind similar to the > kernel, the internal API may change so building out of the tree will > never be very stable, and you still have to comply to GPL. I understand the implication of the change of the API. But I would expect Bluez in the current Debian stable would not change its API much :-) But for the out of the tree solution, I still have the issue with the missing symbol `attrib_db_update`. Any idea? >> Solution B) Moving to the latest Bluez version and use the GATT server >> D-BUS API. But it means I need to remove and replace Bluez on my >> stable Debian. I understand this solution is the long term solution >> but it might take a while before the Linux distributions used this >> version of Bluez. > > If more people like you starting using this features it might become > stable faster, thus we encourage people to go with this solution. Btw, > you can disable the BlueZ from your distro and just run BlueZ from > source without overwriting anything from your distro. > My concern with using a different version of Bluez to the one of my distro is the dependencies with the other applications and Linux kernel that interact with Bluez. There are some potential side effects... >> So, is it possible to have an out of the tree plugin with v5.23? I saw >> `sixaxis` plugin. But this plugin does not manipulate GATT services >> and characteristics. > > Possible, yes, but it is not recommended, but you can try to create a > external plugin that is build within the source tree so that we keep > it working as we change the internal APIs. > The idea behind the out of the tree module was more related to the ease of deployment onto my bluetooth device.If I have to rebuild the bluez Debian package, the deployment will be a bit more complicated (but not much). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-03-02 14:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-02 13:20 Writing an out of the tree new GATT service (for Debian stable): plugin or DBus? Olivier Martin 2016-03-02 14:18 ` Luiz Augusto von Dentz 2016-03-02 14:34 ` Szymon Janc 2016-03-02 14:42 ` Olivier Martin 2016-03-02 14:35 ` Olivier Martin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox