ANN: gsm0710muxd 0.9.1 released

Marcel Holtmann marcel at
Mon Apr 28 13:33:34 CEST 2008

Hi Michael,

> first of all: don't blame mickey, he not responsible at all for the
> muxer code.

I know, but he posted it :)

> second: don't blame me, i am short in time because a muxer was not at
> all on the agenda of what i wanted to do. i know that the code is ugly
> at the protocol-level because that (as you can see on the top) is a
> patchwork from another project. i urgently needed a muxer and om
> wasn't able to provide one. 
> because om all the time promised to deliver a kernel-space-muxer soon
> i didn't want to put too much work in it if it is just for my software
> stack. /if/  more people are really interested in this code i will put
> more work into it and clean it up...  there are lots of thinks i would
> seperate an simplify.

I know the whole story behind it and GSM 07.10 is not fun. Trust me on
that one since I had that specification open on a daily basis for quite
some time.

However for a 0.9.1 release it needs a little bit more love and the code
needs to be a little bit cleaner. I have a hard time reading it and as
mentioned, I do know GSM 07.10 pretty well.

> > On the other hand, the usage of Vala and D-Bus GLib bindings is
> > total overhead for this one. You might wanna have a look into
> > libgdbus which gives you D-Bus wit GLib mainloop integration without
> > the hassle of having an object oriented system. And in this case you
> > only do GObject to get D-Bus support. That introduces a dependency
> > chain that is not justifiable for a system daemon.
> not at all. i see in vala the future for rapid daemon programming.
> there is as far as i understand no overhead in using it, there are no
> more dependencies through it. i used it because everything else was
> not well documented (at least i found nothing) and the vala guy helped
> me alot.

Sorry, but that is non sense.

# ldd src/gsm0710muxd =>  (0x00007fff799ff000) => /usr/lib/ (0x00007f0271589000) => /usr/lib/ (0x00007f027134c000) => /usr/lib/ (0x00007f0271107000) => /usr/lib/ (0x00007f0270e47000) => /lib/ (0x00007f0270ae5000) => /lib/ (0x00007f02708cc000) => /lib/ (0x00007f02706b0000) => /usr/lib/ (0x00007f027048a000)
	/lib64/ (0x00007f02717a9000) => /lib/ (0x00007f0270286000)

You drag the whole libgobject into your dependencies and that is not
needed at all. The only reason you have this is because you are using
the GLib bindings of D-Bus to export a D-Bus interface. That is total
overhead. In this case using libdbus low-level should be the target and
if that is too complicated than go for a helper library like libgdbus.

Nobody says that D-Bus is simple, but that can be easily fixed. Using
Vala and dbus-glib in this specific case is not the solution.

> > > > A simple compile test gives me 159 lines of warnings. These
> > > > should be fixed first since otherwise you start overlooking real
> > > > bugs where the compiler would have warned you.
> > > 
> > > Well, I should probably remove -pedantic -- without it's down to
> > > 6.
> > 
> > Still warnings :)
> thats in generated code ;) i fully agree with you about hidden
> warnings in those hundreds useless ones. perhaps you have a hint on
> which options to use.

One warning in generated code. The others are still in gsm0710muxd.c and
some of them are pretty clear and even without looking at the code, I
can see how to fix them. Also the one in generated code has its root
cause in the non-generated code.

> > > > Also never (I mean never) include C files from another C file.
> > > > If you have no idea on how to use autoconf/automake correctly,
> > > > then ask someone.
> > > 
> > > Hehe, thanks for this "friendly" advice. Actually I do have a clue
> > > about autotools and this part of the MUXer is not my baby, but
> > > yes, we'll fix that later.
> that's the a think i am really not proud of. i will fix it ...see
> above.

I sent a first patch to cleanup this mess. Second would be to cleanup
the Vala generated code inclusion crap.



More information about the gsmd-devel mailing list