Sean McNeil sean at
Fri Feb 13 14:47:06 CET 2009

Michael Trimarchi wrote:
> Hi,
> Sean McNeil wrote:
>> Michael Trimarchi wrote:
>>> Hi,
>>> 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 mailing list