To bluez developers,
With bluez 4.x, support for Embedded GLIB (EGLib) support was dropped,
and GLib became a requirement for bluez.
This presents some challenges for embedded platforms. I want to
present some data from my experience of using both glib and eglib with
bluez 4.6, and suggest that eglib become a supported option for bluez.
-- Size of GLIB compared to EGLIB --
compiled size of glib static library (see file list later) VS eglib:
RAW STRIPPED
libglib.a 2147 k 695 k
libeglib.a 137 k 37 k
compiled size of bluetoothd w/glib compared to bluetoothd w/eglib
RAW STRIPPED
bluetoothd w/glib 1489 k 462 k
bluetoothd w/eglib 530 k 117 k
** bluetoothd _triples_ in size when using glib **
This was for the Android platform - an embedded ARM Linux platform
with our own libc implementation.
glib was compiled statically using only the source files required for
bluetoothd, which are listed at the bottom of this email.
glib has other dependencies that I stubbed out and haven't included in
this data, such as libintl and libiconv. These (if actually required)
would further increase the penalty of using glib.
-- Challenges porting GLIB to a lightweight ARM Linux platform --
We only ported the subset of GLIB needed for bluetoothd, and
customized config.h for the features our platform supported, but still
came across these issues:
- gutils.c expects the platform to have Desktop linux features such as
passwd files, real names for each user etc. I had to stub out
setpwent(), pw_gecos and some friends. Yes bluetoothd requires
gutils.c
- Our libc does not implement bindtextdomain(), dngettext(),
dgettext(), localeconv() which are required for gstrfuncs.c and
gutf8.c. I had to stub them out. These are language translation
features which for many embedded platforms it does not make sense to
support in libc.
- Had to stub out references to libintl, libiconv and libcharset -
again these are translation libraries.
In short, GLIB requires significant modification to compile for a
embedded platform such as Android. These modification are in areas of
code that are required to compile and link, but are code paths that
bluetoothd probably never hits (translation, locales etc). This lack
of modularity suggests that glib was never designed for very
lightweight platforms such as embedded. I am worried about what other
problem we would come across once we start running smoke tests of this
binary etc.
-- Experience building bluetoothd 4.6 with EGLIB from bluez 3.36 --
It was surprisingly easy to compile bluetoothd 4.6 using the eglib
library from bluez 3.36. The only missing functions from eglib were
g_key_file_set_list_separator
g_option_context_add_main_entries
g_option_context_parse
g_option_context_free
For these tests, I just stubbed these out with some simple code. This
allows us to compile bluetoothd with eglib, and it runs and passes
some smoke tests. It would not be a big effort to add these functions
to eglib, and I plan on doing so.
-- Going forwards --
For Android it is a clear win to use eglib rather than glib, and we
will very likely do so once we move to bluez 4.x. I expect many other
embedded platforms will come to the same conclusions. Glib is simply
too bloated and has too many dependencies for many embedded platforms,
and on the other hand it is very easy today to continue using eglib.
Once I have a patch to add the missing functions to eglib, what do the
bluez developers think about returning eglib to the bluez codebase, to
make life easier for embedded developers?
If we do not, then the danger going forwards is that Desktop Bluez
developers will use more and more Desktop orientated features from
glib that are not easily ported to eglib. Without eglib being a
supported configuration, it would require strong discipline from Bluez
to avoid glib features that are not easily ported to embedded.
I guess it comes down to whether Bluez wants to support an embedded
configuration. If Bluez is happy to abandon embedded, then they can
forget eglib. But it Bluez is serious about supporting embedded
configurations, it should keep eglib as a supported option in my
opinion.
I understand that one concern about eglib support is a lack of
maintenance. I would be happy to help out with eglib support.
If supporting eglib is not an option, I am very much interested to
hear the specific reasons as to why not. Is it due to eglib bugs? lack
of eglib features (which ones)? or is embedded just not significant
enough to be a concern?
Perhaps this can be discussed further in Portland.
Nick
PS Marcel - Mono no longer contains an eglib implementation. I haven't
heard back from any of there dev's on what happened to it.
NOTES:
GLIB sources required for bluetoothd
glib/garray.c \
glib/gatomic.c \
glib/gdataset.c \
glib/gconvert.c \
glib/gerror.c \
glib/ghash.c \
glib/gfileutils.c \
glib/giochannel.c \
glib/giounix.c \
glib/glist.c \
glib/gkeyfile.c \
glib/gmain.c \
glib/gmem.c \
glib/gmessages.c \
glib/goption.c \
glib/gpattern.c \
glib/gprintf.c \
glib/grand.c \
glib/gslice.c \
glib/gslist.c \
glib/gstdio.c \
glib/gstrfuncs.c \
glib/gstring.c \
glib/gprimes.c \
glib/gqsort.c \
glib/gtestutils.c \
glib/gthread.c \
glib/gtimer.c \
glib/guniprop.c \
glib/gunidecomp.c \
glib/gutils.c \
glib/gutf8.c \
gmodule/gmodule.c
Hi Nick,
> >> I guess it comes down to whether Bluez wants to support an embedded
> >> configuration. If Bluez is happy to abandon embedded, then they can
> >> forget eglib. But it Bluez is serious about supporting embedded
> >> configurations, it should keep eglib as a supported option in my
> >> opinion.
> >>
> >> I understand that one concern about eglib support is a lack of
> >> maintenance. I would be happy to help out with eglib support.
> >
> > I can bring up a project that contains eglib and we maintain it outside
> > of bluez-4.x source code. You just have to install it first and if you
> > use pkg-config you would have a perfect drop-in replacement. If you
> > compile it by yourself you do whatever fits best.
> >
> >> If supporting eglib is not an option, I am very much interested to
> >> hear the specific reasons as to why not. Is it due to eglib bugs? lack
> >> of eglib features (which ones)? or is embedded just not significant
> >> enough to be a concern?
> >
> > As long as eglib has the same API as GLib it is not a problem of support
> > at all. We do that already. The main reason why we removed it from the
> > source code was that it just became a maintenance nightmare.
> >
> > Do you have a problem to maintain it in a separate source tree and
> > release it as separate packages?
>
> The danger, as I suggested earlier, is that Bluez developers will
> start using API's that are not already implemented in eglib, and do
> not make sense to implement on an embedded platform.
>
> I do not mind maintaining eglib, but I don't want it to become as
> bloated as glib. Bluez needs to make a commitment to only use the
> parts of the glib API that makes sense on embedded platforms as well
> as Desktop platforms. Perhaps in Portland we can go through the API
> and work out what parts of the API that would be.
>
> If Bluez as a project could make that commitment, then I would be
> happy to maintain eglib in a separate source tree.
it will not happen that BlueZ makes such a commitment. BlueZ works
perfectly fine on embedded systems and GLib is not as bloated as you
thing. You just happen to have a specific and limited use case scenario.
If we start to use functions not implemented in eglib, then you have to
implement them. That is what we were doing for the last 3 years and it
slowed down the development of BlueZ. This is why non of the BlueZ
developers are doing this anymore.
I created the initial tree for eglib at kernel.org:
http://git.kernel.org/?p=bluetooth/eglib.git;a=summary
Feel free to sent me patches against it.
And just to make this perfectly clear, bashing against GLib doesn't help
at all. You either go ahead and make GLib more suitable for your needs
or you do this in eglib. Just using kernel features like epoll, timerfd
etc. would help you a lot to achieve your goal. Just make sure eglib is
API compatible.
I take care of the release process of eglib, but no other BlueZ
developer can be bothered with eglib details.
Regards
Marcel
+1 to maintain eglib out of BlueZ code, we already have enough trouble
with releases because eglib, this is not really a problem of BlueZ
using glib but glib being bloated so fixing glib by distributing eglib
on its place might fix everybody problems. If we got a replacement for
glib we would probably stick to it since glib is at least unreadable,
there is even a case where a 'if (0)' was being used in its code (I
really meant glib not eglib).
I remember Marcel commenting about a library which Lennart was
supposed to implement, something I would like libdbus itself supports,
which would be a low level dbus api + mainloop + helpers which most
system daemons would be using to get into dbus system bus. All daemons
require mainloops (including dbus-daemon itself) so this may probably
be an opportunity to get this done and remove glib dependency from
dbus system daemons space.
--=20
Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o
On Fri, Sep 19, 2008 at 5:39 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Nick,
>
>> With bluez 4.x, support for Embedded GLIB (EGLib) support was dropped,
>> and GLib became a requirement for bluez.
>>
>> This presents some challenges for embedded platforms. I want to
>> present some data from my experience of using both glib and eglib with
>> bluez 4.6, and suggest that eglib become a supported option for bluez.
>>
>> -- Size of GLIB compared to EGLIB --
>>
>> compiled size of glib static library (see file list later) VS eglib:
>> RAW STRIPPED
>> libglib.a 2147 k 695 k
>> libeglib.a 137 k 37 k
>>
>> compiled size of bluetoothd w/glib compared to bluetoothd w/eglib
>> RAW STRIPPED
>> bluetoothd w/glib 1489 k 462 k
>> bluetoothd w/eglib 530 k 117 k
>>
>> ** bluetoothd _triples_ in size when using glib **
>
> I assume that you are talking about GLib statically linked into
> bluetoothd.
Yes, I was using static linking.
>
>> I guess it comes down to whether Bluez wants to support an embedded
>> configuration. If Bluez is happy to abandon embedded, then they can
>> forget eglib. But it Bluez is serious about supporting embedded
>> configurations, it should keep eglib as a supported option in my
>> opinion.
>>
>> I understand that one concern about eglib support is a lack of
>> maintenance. I would be happy to help out with eglib support.
>
> I can bring up a project that contains eglib and we maintain it outside
> of bluez-4.x source code. You just have to install it first and if you
> use pkg-config you would have a perfect drop-in replacement. If you
> compile it by yourself you do whatever fits best.
>
>> If supporting eglib is not an option, I am very much interested to
>> hear the specific reasons as to why not. Is it due to eglib bugs? lack
>> of eglib features (which ones)? or is embedded just not significant
>> enough to be a concern?
>
> As long as eglib has the same API as GLib it is not a problem of support
> at all. We do that already. The main reason why we removed it from the
> source code was that it just became a maintenance nightmare.
>
> Do you have a problem to maintain it in a separate source tree and
> release it as separate packages?
The danger, as I suggested earlier, is that Bluez developers will
start using API's that are not already implemented in eglib, and do
not make sense to implement on an embedded platform.
I do not mind maintaining eglib, but I don't want it to become as
bloated as glib. Bluez needs to make a commitment to only use the
parts of the glib API that makes sense on embedded platforms as well
as Desktop platforms. Perhaps in Portland we can go through the API
and work out what parts of the API that would be.
If Bluez as a project could make that commitment, then I would be
happy to maintain eglib in a separate source tree.
Nick
Hi Nick,
> With bluez 4.x, support for Embedded GLIB (EGLib) support was dropped,
> and GLib became a requirement for bluez.
>
> This presents some challenges for embedded platforms. I want to
> present some data from my experience of using both glib and eglib with
> bluez 4.6, and suggest that eglib become a supported option for bluez.
>
> -- Size of GLIB compared to EGLIB --
>
> compiled size of glib static library (see file list later) VS eglib:
> RAW STRIPPED
> libglib.a 2147 k 695 k
> libeglib.a 137 k 37 k
>
> compiled size of bluetoothd w/glib compared to bluetoothd w/eglib
> RAW STRIPPED
> bluetoothd w/glib 1489 k 462 k
> bluetoothd w/eglib 530 k 117 k
>
> ** bluetoothd _triples_ in size when using glib **
I assume that you are talking about GLib statically linked into
bluetoothd. Systems that already have GLib anyway benefit from it.
> I guess it comes down to whether Bluez wants to support an embedded
> configuration. If Bluez is happy to abandon embedded, then they can
> forget eglib. But it Bluez is serious about supporting embedded
> configurations, it should keep eglib as a supported option in my
> opinion.
>
> I understand that one concern about eglib support is a lack of
> maintenance. I would be happy to help out with eglib support.
I can bring up a project that contains eglib and we maintain it outside
of bluez-4.x source code. You just have to install it first and if you
use pkg-config you would have a perfect drop-in replacement. If you
compile it by yourself you do whatever fits best.
> If supporting eglib is not an option, I am very much interested to
> hear the specific reasons as to why not. Is it due to eglib bugs? lack
> of eglib features (which ones)? or is embedded just not significant
> enough to be a concern?
As long as eglib has the same API as GLib it is not a problem of support
at all. We do that already. The main reason why we removed it from the
source code was that it just became a maintenance nightmare.
Do you have a problem to maintain it in a separate source tree and
release it as separate packages?
Regards
Marcel