sean at mcneil.com
Fri Feb 13 14:36:03 CET 2009
Michael Trimarchi wrote:
> Sean McNeil wrote:
>> Hi Michael,
>> This is a very bad idea for several reasons:
>> 1) You cannot guarantee which pts you get.
> Yes I can, it is just a script property.
No you can't. You do not know that something else is using pts or not.
You cannot guarantee that you will get /dev/pts/0 when you first open
/dev/ptmx. Also there is a startup race condition. You have to know that
the mux daemon is up and has allocated the pts before you can possibly
pass it to the rild. The OM stack uses dbus to get around that. The pts
isn't allocated until needed and then the actual device is passed back.
It doesn't sound like you are doing that and rild isn't setup to use
dbus. If you bundle it into a script you still have possible race
conditions. Plus if the script dies, then you need to make sure
processes are not still around (mux and ril) before you try to start up
again. It just makes things a lot more complicated when it doesn't need
>> 2) You expose the modem so that it can be accessed by anyone.
> Can you clarify this point?
You stated that you create a series of terminals. Any one of those
terminals can then be opened and control the modem. They could even
issue an ATZ and reset it. The mux is going to expose at least 2 - 1 for
rild and 1 for gprs. Your implementation would expose the gprs in modem
command mode at the very least. The issue here is that only the rild
should have any means to talk to the modem in command mode.
>> 3) It makes things difficult to recover when there is a problem.
> The freerunner-fso is not use a daemon for multiplexing?
They use dbus, but there are still some issues with recovery in their
design. They do a much better job, however, than you could do in
combination with rild. The rild just isn't designed to have another
layer between it and the modem. Also, the rild is designed to be the
only way to access the modem (voice and data), so there shouldn't be an
external means to get access.
>> 4) Yet another layer to deal with.
> The other layer is a serial device abstraction, so if it is well
> written, I don't think that can
> be problem
I've just outlined several reasons, but the biggest concern for us has
been security. Even in an open platform you want security as malicious
apps can be downloaded that might take over the modem.
>> This it the method that TI took and we are working with them on a
>> better solution.
>> Michael Trimarchi wrote:
>>> Hi all,
>>> I write a daemon like gsmmuxd that virtualize the serial driver and
>>> export a series of terminal for
>>> the rild service, gprs service etc. The rild service start using the
>>> /dev/pts/0 terminal. I grant it to him
>>> when the channel is ready. The daemon is not releated to the rild,
>>> it just give an openchannel. I don't
>>> use an extra channel for unsolicited command, because the android
>>> ril don't use it, but I suppose that a
>>> gprs connection can be initialize on /dev/pts/xxx. Only one question
>>> just to know:
>>> Have I some license problem if I use a separate daemon for
More information about the openmoko-kernel