ANN: gsm0710muxd 0.9.1 released

M. Dietrich mdt at emdete.de
Mon Apr 28 13:00:21 CEST 2008


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



More information about the openmoko-devel mailing list