[RFC] Reorganizing the BlueZ source tree

[RFC] Reorganizing the BlueZ source tree

[Gustavo Padovan]

Hi Everyone,

The last profiles addition to BlueZ increased a lot the number of folders we
have in the root dir of the project and it looks like more profiles (and more
folders) are expected to come.

I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
the following proposal where 2 new folders are created, 'profiles' and 'libs'
and things are moved to them.

compat          -> /dev/null (will be removed on 5.0)
alert           -> profiles
audio           -> profiles
cups            -> profiles
deviceinfo      -> profiles
health          -> profiles
input           -> profiles
lib             -> profiles
network         -> profiles
proximity       -> profiles
sap             -> profiles
serial          -> profiles
thermometer     -> profiles
time            -> profiles
btio            -> libs
gdbus           -> libs
sbc             -> libs
emulator        -> tools
mgmt            -> tools
monitor         -> tools
attrib
doc
plugins
scripts
src
test
tools
unit


In the end we will have 10 folders instead of 28 in the current configuration.
Folders like 'tools' can also be reorganized.

	Gustavo

Re: [RFC] Reorganizing the BlueZ source tree

[Luiz Augusto von Dentz]

Hi Gustavo,

On Thu, May 24, 2012 at 11:14 AM, Gustavo Padovan <gustavo@padovan.org> wrote:
> Hi Everyone,
>
> The last profiles addition to BlueZ increased a lot the number of folders we
> have in the root dir of the project and it looks like more profiles (and more
> folders) are expected to come.
>
> I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> the following proposal where 2 new folders are created, 'profiles' and 'libs'
> and things are moved to them.
>
> compat          -> /dev/null (will be removed on 5.0)
> alert           -> profiles
> audio           -> profiles
> cups            -> profiles
> deviceinfo      -> profiles
> health          -> profiles
> input           -> profiles
> lib             -> profiles
> network         -> profiles
> proximity       -> profiles
> sap             -> profiles
> serial          -> profiles
> thermometer     -> profiles
> time            -> profiles
> btio            -> libs
> gdbus           -> libs
> sbc             -> libs
> emulator        -> tools
> mgmt            -> tools
> monitor         -> tools
> attrib
> doc
> plugins
> scripts
> src
> test
> tools
> unit

Sounds good, the only problem are gdbus and btio, if we merge obexd
into BlueZ btio will no longer be shared but for gdbus we would have
to align with other projects as well.

-- 
Luiz Augusto von Dentz

Re: [RFC] Reorganizing the BlueZ source tree

[Johan Hedberg]

Hi Gustavo,

On Thu, May 24, 2012, Gustavo Padovan wrote:
> lib             -> profiles

Was this a typo? I'd have suggested to rename the existing "lib" to the
new "libs" and after that start moving the other "lib" subdirectories
there. The existing content of lib might also be reorganized, e.g. move
SDP code into libs/sdp/

Johan

Re: [RFC] Reorganizing the BlueZ source tree

[Gustavo Padovan]

Hi Johan,

* Johan Hedberg <johan.hedberg@gmail.com> [2012-05-24 11:23:52 +0300]:

> Hi Gustavo,
> 
> On Thu, May 24, 2012, Gustavo Padovan wrote:
> > lib             -> profiles
> 
> Was this a typo? I'd have suggested to rename the existing "lib" to the
> new "libs" and after that start moving the other "lib" subdirectories
> there. The existing content of lib might also be reorganized, e.g. move
> SDP code into libs/sdp/

Yes, it is a typo. lib -> libs was the right assignment here.

	Gustavo

Re: [RFC] Reorganizing the BlueZ source tree

[Marcel Holtmann]

Hi Luiz,

> > The last profiles addition to BlueZ increased a lot the number of folders we
> > have in the root dir of the project and it looks like more profiles (and more
> > folders) are expected to come.
> >
> > I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> > the following proposal where 2 new folders are created, 'profiles' and 'libs'
> > and things are moved to them.
> >
> > compat          -> /dev/null (will be removed on 5.0)
> > alert           -> profiles
> > audio           -> profiles
> > cups            -> profiles
> > deviceinfo      -> profiles
> > health          -> profiles
> > input           -> profiles
> > lib             -> profiles
> > network         -> profiles
> > proximity       -> profiles
> > sap             -> profiles
> > serial          -> profiles
> > thermometer     -> profiles
> > time            -> profiles
> > btio            -> libs
> > gdbus           -> libs
> > sbc             -> libs
> > emulator        -> tools
> > mgmt            -> tools
> > monitor         -> tools
> > attrib
> > doc
> > plugins
> > scripts
> > src
> > test
> > tools
> > unit
> 
> Sounds good, the only problem are gdbus and btio, if we merge obexd
> into BlueZ btio will no longer be shared but for gdbus we would have
> to align with other projects as well.

btio, gdbus, gobex and similar stay top-level. We are not going to
change that.

Regards

Marcel

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Thu, 2012-05-24 at 11:20 +0300, Luiz Augusto von Dentz wrote:
> Hi Gustavo,
> 
> On Thu, May 24, 2012 at 11:14 AM, Gustavo Padovan <gustavo@padovan.org> wrote:
> > Hi Everyone,
> >
> > The last profiles addition to BlueZ increased a lot the number of folders we
> > have in the root dir of the project and it looks like more profiles (and more
> > folders) are expected to come.
> >
> > I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> > the following proposal where 2 new folders are created, 'profiles' and 'libs'
> > and things are moved to them.
> >
> > compat          -> /dev/null (will be removed on 5.0)
> > alert           -> profiles
> > audio           -> profiles
> > cups            -> profiles
> > deviceinfo      -> profiles
> > health          -> profiles
> > input           -> profiles
> > lib             -> profiles
> > network         -> profiles
> > proximity       -> profiles
> > sap             -> profiles
> > serial          -> profiles
> > thermometer     -> profiles
> > time            -> profiles
> > btio            -> libs
> > gdbus           -> libs
> > sbc             -> libs
> > emulator        -> tools
> > mgmt            -> tools
> > monitor         -> tools
> > attrib
> > doc
> > plugins
> > scripts
> > src
> > test
> > tools
> > unit
> 
> Sounds good, the only problem are gdbus and btio, if we merge obexd
> into BlueZ btio will no longer be shared but for gdbus we would have
> to align with other projects as well.

While you're at it, change gdbus' name to something that doesn't clash
with the GIO GDBus.

Re: [RFC] Reorganizing the BlueZ source tree

[Marcel Holtmann]

Hi Bastien,

> > > The last profiles addition to BlueZ increased a lot the number of folders we
> > > have in the root dir of the project and it looks like more profiles (and more
> > > folders) are expected to come.
> > >
> > > I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> > > the following proposal where 2 new folders are created, 'profiles' and 'libs'
> > > and things are moved to them.
> > >
> > > compat          -> /dev/null (will be removed on 5.0)
> > > alert           -> profiles
> > > audio           -> profiles
> > > cups            -> profiles
> > > deviceinfo      -> profiles
> > > health          -> profiles
> > > input           -> profiles
> > > lib             -> profiles
> > > network         -> profiles
> > > proximity       -> profiles
> > > sap             -> profiles
> > > serial          -> profiles
> > > thermometer     -> profiles
> > > time            -> profiles
> > > btio            -> libs
> > > gdbus           -> libs
> > > sbc             -> libs
> > > emulator        -> tools
> > > mgmt            -> tools
> > > monitor         -> tools
> > > attrib
> > > doc
> > > plugins
> > > scripts
> > > src
> > > test
> > > tools
> > > unit
> > 
> > Sounds good, the only problem are gdbus and btio, if we merge obexd
> > into BlueZ btio will no longer be shared but for gdbus we would have
> > to align with other projects as well.
> 
> While you're at it, change gdbus' name to something that doesn't clash
> with the GIO GDBus.

why would we? This code predates GIO GDBus.

Regards

Marcel

Re: [RFC] Reorganizing the BlueZ source tree

[Joao Paulo Rechi Vita]

On Thu, May 24, 2012 at 5:14 AM, Gustavo Padovan <gustavo@padovan.org> wrote:
> Hi Everyone,
>
> The last profiles addition to BlueZ increased a lot the number of folders we
> have in the root dir of the project and it looks like more profiles (and more
> folders) are expected to come.
>
> I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> the following proposal where 2 new folders are created, 'profiles' and 'libs'
> and things are moved to them.
>
> compat          -> /dev/null (will be removed on 5.0)
> alert           -> profiles
> audio           -> profiles
> cups            -> profiles
> deviceinfo      -> profiles
> health          -> profiles
> input           -> profiles
> lib             -> profiles
> network         -> profiles
> proximity       -> profiles
> sap             -> profiles
> serial          -> profiles
> thermometer     -> profiles
> time            -> profiles
> btio            -> libs
> gdbus           -> libs
> sbc             -> libs
> emulator        -> tools
> mgmt            -> tools
> monitor         -> tools
> attrib

attrib needs a bit of reorganization as well. tl;dr: we need to figure
how to do it.

gatttool should be moved from attrib to tools, and we're not
completely sure where to put the rest of it. The code there implements
the generic attribute API, which register a D-Bus interface but is not
a profile plugin, since there is nothing to trigger its probe.
Additionally, this API is concurrent with some of the profiles we have
now implemented, so I think there should be a way to enable/disable it
based on user configuration (then it would work pretty much as a
profile, what could be an argument to move it to 'profiles', but is
not a profile from the spec point of view, which is an argument
against it).

> doc
> plugins
> scripts
> src
> test
> tools

What is the differentiation between test and tools? It seems at least
part of tests (simple-agent for example) looks more like a tool than
like a simple test script.

> unit

Why not move unit tests to tests as well?

>
>
> In the end we will have 10 folders instead of 28 in the current configuration.
> Folders like 'tools' can also be reorganized.
>

I'm really supportive of this idea.

-- 
João Paulo Rechi Vita
Openbossa Labs - INdT

Re: [RFC] Reorganizing the BlueZ source tree

[Lucas De Marchi]

On Thu, May 24, 2012 at 5:34 AM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
> Hi Luiz,
>
>> > The last profiles addition to BlueZ increased a lot the number of fold=
ers we
>> > have in the root dir of the project and it looks like more profiles (a=
nd more
>> > folders) are expected to come.
>> >
>> > I talked a bit with Johan about changing the hierarchy of the BlueZ tr=
ee and
>> > the following proposal where 2 new folders are created, 'profiles' and=
 'libs'
>> > and things are moved to them.
>> >
>> > compat =A0 =A0 =A0 =A0 =A0-> /dev/null (will be removed on 5.0)
>> > alert =A0 =A0 =A0 =A0 =A0 -> profiles
>> > audio =A0 =A0 =A0 =A0 =A0 -> profiles
>> > cups =A0 =A0 =A0 =A0 =A0 =A0-> profiles
>> > deviceinfo =A0 =A0 =A0-> profiles
>> > health =A0 =A0 =A0 =A0 =A0-> profiles
>> > input =A0 =A0 =A0 =A0 =A0 -> profiles
>> > lib =A0 =A0 =A0 =A0 =A0 =A0 -> profiles
>> > network =A0 =A0 =A0 =A0 -> profiles
>> > proximity =A0 =A0 =A0 -> profiles
>> > sap =A0 =A0 =A0 =A0 =A0 =A0 -> profiles
>> > serial =A0 =A0 =A0 =A0 =A0-> profiles
>> > thermometer =A0 =A0 -> profiles
>> > time =A0 =A0 =A0 =A0 =A0 =A0-> profiles
>> > btio =A0 =A0 =A0 =A0 =A0 =A0-> libs
>> > gdbus =A0 =A0 =A0 =A0 =A0 -> libs
>> > sbc =A0 =A0 =A0 =A0 =A0 =A0 -> libs
>> > emulator =A0 =A0 =A0 =A0-> tools
>> > mgmt =A0 =A0 =A0 =A0 =A0 =A0-> tools
>> > monitor =A0 =A0 =A0 =A0 -> tools
>> > attrib
>> > doc
>> > plugins
>> > scripts
>> > src
>> > test
>> > tools
>> > unit
>>
>> Sounds good, the only problem are gdbus and btio, if we merge obexd
>> into BlueZ btio will no longer be shared but for gdbus we would have
>> to align with other projects as well.
>
> btio, gdbus, gobex and similar stay top-level. We are not going to
> change that.

If you are concerned about sharing gdbus patches, git am could do the
work for you: "git am --directory=3Dlibs/"

But I'm not convinced about the "libs" directory... maybe move only profile=
s?


Lucas De Marchi

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Thu, 2012-05-24 at 12:05 +0200, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > > The last profiles addition to BlueZ increased a lot the number of folders we
> > > > have in the root dir of the project and it looks like more profiles (and more
> > > > folders) are expected to come.
> > > >
> > > > I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> > > > the following proposal where 2 new folders are created, 'profiles' and 'libs'
> > > > and things are moved to them.
> > > >
> > > > compat          -> /dev/null (will be removed on 5.0)
> > > > alert           -> profiles
> > > > audio           -> profiles
> > > > cups            -> profiles
> > > > deviceinfo      -> profiles
> > > > health          -> profiles
> > > > input           -> profiles
> > > > lib             -> profiles
> > > > network         -> profiles
> > > > proximity       -> profiles
> > > > sap             -> profiles
> > > > serial          -> profiles
> > > > thermometer     -> profiles
> > > > time            -> profiles
> > > > btio            -> libs
> > > > gdbus           -> libs
> > > > sbc             -> libs
> > > > emulator        -> tools
> > > > mgmt            -> tools
> > > > monitor         -> tools
> > > > attrib
> > > > doc
> > > > plugins
> > > > scripts
> > > > src
> > > > test
> > > > tools
> > > > unit
> > > 
> > > Sounds good, the only problem are gdbus and btio, if we merge obexd
> > > into BlueZ btio will no longer be shared but for gdbus we would have
> > > to align with other projects as well.
> > 
> > While you're at it, change gdbus' name to something that doesn't clash
> > with the GIO GDBus.
> 
> why would we? This code predates GIO GDBus.

Because people told you that your naming would clash once glib had an
implementation of D-Bus, which you just laughed away.

Re: [RFC] Reorganizing the BlueZ source tree

[Marcel Holtmann]

Hi Bastien,

> > > > > The last profiles addition to BlueZ increased a lot the number of folders we
> > > > > have in the root dir of the project and it looks like more profiles (and more
> > > > > folders) are expected to come.
> > > > >
> > > > > I talked a bit with Johan about changing the hierarchy of the BlueZ tree and
> > > > > the following proposal where 2 new folders are created, 'profiles' and 'libs'
> > > > > and things are moved to them.
> > > > >
> > > > > compat          -> /dev/null (will be removed on 5.0)
> > > > > alert           -> profiles
> > > > > audio           -> profiles
> > > > > cups            -> profiles
> > > > > deviceinfo      -> profiles
> > > > > health          -> profiles
> > > > > input           -> profiles
> > > > > lib             -> profiles
> > > > > network         -> profiles
> > > > > proximity       -> profiles
> > > > > sap             -> profiles
> > > > > serial          -> profiles
> > > > > thermometer     -> profiles
> > > > > time            -> profiles
> > > > > btio            -> libs
> > > > > gdbus           -> libs
> > > > > sbc             -> libs
> > > > > emulator        -> tools
> > > > > mgmt            -> tools
> > > > > monitor         -> tools
> > > > > attrib
> > > > > doc
> > > > > plugins
> > > > > scripts
> > > > > src
> > > > > test
> > > > > tools
> > > > > unit
> > > > 
> > > > Sounds good, the only problem are gdbus and btio, if we merge obexd
> > > > into BlueZ btio will no longer be shared but for gdbus we would have
> > > > to align with other projects as well.
> > > 
> > > While you're at it, change gdbus' name to something that doesn't clash
> > > with the GIO GDBus.
> > 
> > why would we? This code predates GIO GDBus.
> 
> Because people told you that your naming would clash once glib had an
> implementation of D-Bus, which you just laughed away.

and I still have all the rights to do so.

As long as we are still based on GLib, this will stay as it is. I am not
jumping through any hoops, because David wouldn't respect prior art.

Regards

Marcel

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Thu, 2012-06-07 at 07:59 +0900, Marcel Holtmann wrote:
> 
> and I still have all the rights to do so.
> 
> As long as we are still based on GLib, this will stay as it is. I am
> not
> jumping through any hoops, because David wouldn't respect prior art.

How exactly would would have called a D-Bus implementation in GLib?

Re: [RFC] Reorganizing the BlueZ source tree

[Luiz Augusto von Dentz]

Hi Bastien

On Fri, Jun 8, 2012 at 12:44 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Thu, 2012-06-07 at 07:59 +0900, Marcel Holtmann wrote:
>>
>> and I still have all the rights to do so.
>>
>> As long as we are still based on GLib, this will stay as it is. I am
>> not
>> jumping through any hoops, because David wouldn't respect prior art.
>
> How exactly would would have called a D-Bus implementation in GLib?

Well you could have called godbus as that is more a gobject binding
than a pure glib/GMainLoop one.



-- 
Luiz Augusto von Dentz

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Fri, 2012-06-08 at 13:02 +0300, Luiz Augusto von Dentz wrote:
> Hi Bastien
> 
> On Fri, Jun 8, 2012 at 12:44 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Thu, 2012-06-07 at 07:59 +0900, Marcel Holtmann wrote:
> >>
> >> and I still have all the rights to do so.
> >>
> >> As long as we are still based on GLib, this will stay as it is. I am
> >> not
> >> jumping through any hoops, because David wouldn't respect prior art.
> >
> > How exactly would would have called a D-Bus implementation in GLib?
> 
> Well you could have called godbus as that is more a gobject binding
> than a pure glib/GMainLoop one.

GLib lives in a single tarball. It's only Marcel's hate for GObject and
the apparent need to be able to replace glib that spawned this thin
wrapper on top of libdbus you're using now.

GLib's APIs don't differentiate which shared library they come from.

Re: [RFC] Reorganizing the BlueZ source tree

[Marcel Holtmann]

Hi Bastien,

> > >> and I still have all the rights to do so.
> > >>
> > >> As long as we are still based on GLib, this will stay as it is. I am
> > >> not
> > >> jumping through any hoops, because David wouldn't respect prior art.
> > >
> > > How exactly would would have called a D-Bus implementation in GLib?
> > 
> > Well you could have called godbus as that is more a gobject binding
> > than a pure glib/GMainLoop one.
> 
> GLib lives in a single tarball. It's only Marcel's hate for GObject and
> the apparent need to be able to replace glib that spawned this thin
> wrapper on top of libdbus you're using now.

plain fact is that our gdbus code was there first.

If you wanna turn this into a GObject discussion now, then please find a
mailing list that cares. It is clearly not this one.

Regards

Marcel

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Fri, 2012-06-08 at 20:46 +0900, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > >> and I still have all the rights to do so.
> > > >>
> > > >> As long as we are still based on GLib, this will stay as it is. I am
> > > >> not
> > > >> jumping through any hoops, because David wouldn't respect prior art.
> > > >
> > > > How exactly would would have called a D-Bus implementation in GLib?
> > > 
> > > Well you could have called godbus as that is more a gobject binding
> > > than a pure glib/GMainLoop one.
> > 
> > GLib lives in a single tarball. It's only Marcel's hate for GObject and
> > the apparent need to be able to replace glib that spawned this thin
> > wrapper on top of libdbus you're using now.
> 
> plain fact is that our gdbus code was there first.

Nice comeback.

> If you wanna turn this into a GObject discussion now,

I don't. I'm merely pointing out that a file layout change might be a
good time to fix potential symbol clashes.

>  then please find a
> mailing list that cares. It is clearly not this one.

I think you've made this abundantly clear. I don't think this attitude
is helping BlueZ thrive, when it's far less friction to fix problems
higher up in the stack.

Re: [RFC] Reorganizing the BlueZ source tree

[Marcel Holtmann]

Hi Bastien,

> > > > >> and I still have all the rights to do so.
> > > > >>
> > > > >> As long as we are still based on GLib, this will stay as it is. I am
> > > > >> not
> > > > >> jumping through any hoops, because David wouldn't respect prior art.
> > > > >
> > > > > How exactly would would have called a D-Bus implementation in GLib?
> > > > 
> > > > Well you could have called godbus as that is more a gobject binding
> > > > than a pure glib/GMainLoop one.
> > > 
> > > GLib lives in a single tarball. It's only Marcel's hate for GObject and
> > > the apparent need to be able to replace glib that spawned this thin
> > > wrapper on top of libdbus you're using now.
> > 
> > plain fact is that our gdbus code was there first.
> 
> Nice comeback.
> 
> > If you wanna turn this into a GObject discussion now,
> 
> I don't. I'm merely pointing out that a file layout change might be a
> good time to fix potential symbol clashes.
> 
> >  then please find a
> > mailing list that cares. It is clearly not this one.
> 
> I think you've made this abundantly clear. I don't think this attitude
> is helping BlueZ thrive, when it's far less friction to fix problems
> higher up in the stack.

we will move away from GLib and libdbus (and also libnl) altogether at
some point soon anyway. Then this discussion becomes mood.

Our problems are the memory footprint and the abstractions done purely
for making this run on Windows. With the embedded consumer electronics
devices that we target this is creating more and more issues these days.

Regards

Marcel

Re: [RFC] Reorganizing the BlueZ source tree

[Bastien Nocera]

On Fri, 2012-06-08 at 21:07 +0900, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > > > >> and I still have all the rights to do so.
> > > > > >>
> > > > > >> As long as we are still based on GLib, this will stay as it is. I am
> > > > > >> not
> > > > > >> jumping through any hoops, because David wouldn't respect prior art.
> > > > > >
> > > > > > How exactly would would have called a D-Bus implementation in GLib?
> > > > > 
> > > > > Well you could have called godbus as that is more a gobject binding
> > > > > than a pure glib/GMainLoop one.
> > > > 
> > > > GLib lives in a single tarball. It's only Marcel's hate for GObject and
> > > > the apparent need to be able to replace glib that spawned this thin
> > > > wrapper on top of libdbus you're using now.
> > > 
> > > plain fact is that our gdbus code was there first.
> > 
> > Nice comeback.
> > 
> > > If you wanna turn this into a GObject discussion now,
> > 
> > I don't. I'm merely pointing out that a file layout change might be a
> > good time to fix potential symbol clashes.
> > 
> > >  then please find a
> > > mailing list that cares. It is clearly not this one.
> > 
> > I think you've made this abundantly clear. I don't think this attitude
> > is helping BlueZ thrive, when it's far less friction to fix problems
> > higher up in the stack.
> 
> we will move away from GLib and libdbus (and also libnl) altogether at
> some point soon anyway. Then this discussion becomes mood.

Will you be implementing your own D-Bus library, or do you have plans to
switch to something completely different?

> Our problems are the memory footprint and the abstractions done purely
> for making this run on Windows.

The abstraction aren't there for Windows, they're there to allow for
better APIs, avoiding functional changes in the underlying system[1] and
making developer's lives easier.

>  With the embedded consumer electronics
> devices that we target this is creating more and more issues these days.

When consumer electronics are faster and faster, and with more and more
RAM, I doubt that GLib or GObject's memory footprint is a huge issue.
I'm not saying it's not an issue at all, but I doubt it's what causes
problems (versus missing features for example) when vendors select a
Linux Bluetooth stack.

[1]: the application developer shouldn't have to choose whether inotify,
fanotify or FAM is better suited for their file monitoring support for
example, or which one is going to work with which version of the kernel,
or which storage. Being able to use GIO for that purpose would have made
the adaptername plugin much simpler for example.