2016-03-02 13:20:57

by Olivier Martin

[permalink] [raw]
Subject: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus?

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


2016-03-02 14:42:26

by Olivier Martin

[permalink] [raw]
Subject: Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus?

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 <[email protected]> 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
>>
>> <[email protected]> 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

2016-03-02 14:35:56

by Olivier Martin

[permalink] [raw]
Subject: Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus?

Thanks Luiz for your answer!

On 2 March 2016 at 14:18, Luiz Augusto von Dentz <[email protected]> wrote:
> Hi Olivier,
>
> On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin
> <[email protected]> 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).

2016-03-02 14:34:20

by Szymon Janc

[permalink] [raw]
Subject: Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus?

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
>
> <[email protected]> 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

2016-03-02 14:18:22

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: Writing an out of the tree new GATT service (for Debian stable): plugin or DBus?

Hi Olivier,

On Wed, Mar 2, 2016 at 3:20 PM, Olivier Martin
<[email protected]> 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