MUXer issues

Andy Green andy at
Fri May 30 11:18:40 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On 29/05/2008, Michael 'Mickey' Lauer <mickey at> wrote:
|>> We can configure dbus and glib out then, simplifying this project?
|> Scratch my previous reply to that sentence, I misread configuring out as
|>  ripping out. Yes, I think a patch that makes configuring a static amount
|>  of MUXing channels hence dbus and glib optional would be acceptable.
| Err, is there a performance gain from that? We already have the whole
| system use D-bus and it's not a bother in the the case of muxd.
| Dynamic allocation of DLCs allows one to run an arbitrary application
| that uses modem without disturbing our GSM stack (ok, depends on the
| application but in many cases this is the case).  Even the kernel
| implementations were designed to have DLCs allocated dynamically as
| requested by userspace by opening or closing an appropriate /dev/
| node, much like ptys in Linux.

No, there is no performance gain other than debloating it and
disallowing a class of problems around the configuration.  Just trying
to get rid of dependencies, complexity, bloat in a little daemon that is
just meant to stitch raw data into a mux stream.  It should be really
lightweight, shouldn't it?

Do we want to support low level applications that can talk to the modem
in +++AT language behind our backs?  Sounds like we should instead have
one "customer" for this channel that manages actions on the channel.  I
read that gsmd is getting the boot but I guess I am thinking about a
gsmd-type manager for high level modem actions in userspace.  What is
the plan about replacing gsmd (if I didn't misunderstand its future)?

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list