sean at mcneil.com
Fri Feb 13 14:47:06 CET 2009
Michael Trimarchi wrote:
> Sean McNeil wrote:
>> 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 to be.
> This is can be done by a property setting
> on property:vchanneld.status=start
> start ril-daemon
> You can give the serial device to the rild setting property.
Again, no. You cannot guarantee that the property will be set before the
rild gets started. This is a race condition. Also, when/if the rild
aborts then the pts will no longer be available as it gets closed.
You'll never be able to talk to the modem again.
More information about the openmoko-kernel