Hi Marcel, first of all: don't blame mickey, he not responsible at all for the muxer code.
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. On Mon, Apr 28, 2008 at 12:16:01PM +0200, Marcel Holtmann wrote: > > > what about including the original vala and marshal source files > > > and have them auto-generated at compile time. > > > > Not until vala reaches 1.0. I have only one Vala version in OE and > > I can't afford updating all vala-users everytime I bump it. > > but you can simply include all *.vala and *.marshal files in the > tarball to have them at least for reference. i will commit the vala and xml source for reference. > > 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. > > > > 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. > > > 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. > If you really think that having the GSM 07.10 in userspace is better > than the kernel solution, this code needs massive cleanup. It is > almost impossible to review this code. as i said: i never wanted to do this thing. i needed this thing. if there is a kernel muxer that works we can start discussing which one is the better choice. until then i will use a user-space one. and if the discussion says user-space is fine, i will cleanup the code. promissed. > Can you setup a git repository somewhere. Doing tarball only > releases is not really helpful. gsm0710muxd is in a svn repo. that should be fine. best regards, michael