ANN: gsm0710muxd 0.9.1 released

Marcel Holtmann marcel at holtmann.org
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
	linux-vdso.so.1 =>  (0x00007fff799ff000)
	libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f0271589000)
	libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f027134c000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f0271107000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f0270e47000)
	libc.so.6 => /lib/libc.so.6 (0x00007f0270ae5000)
	libnsl.so.1 => /lib/libnsl.so.1 (0x00007f02708cc000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007f02706b0000)
	libpcre.so.3 => /usr/lib/libpcre.so.3 (0x00007f027048a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f02717a9000)
	libdl.so.2 => /lib/libdl.so.2 (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.

Regards

Marcel





More information about the openmoko-devel mailing list