-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On 29/05/2008, Michael 'Mickey' Lauer <[EMAIL PROTECTED]> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkg/xnAACgkQOjLpvpq7dMokoACfYQsw/ZSL0F+2XTT6U6Kj923I 2SEAn2VAsbDBfQqvaSjK3LuiGfQzXG+d =G91E -----END PGP SIGNATURE-----
