andy at openmoko.com
Fri May 30 11:18:40 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| On 29/05/2008, Michael 'Mickey' Lauer <mickey at openmoko.org> 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)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel