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