vchanneld

[Sean McNeil]

Michael Trimarchi wrote:
> Hi,
>
> Sean McNeil wrote:
>> 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.
>>
>>
> The rild start disable. The vchanneld start and initialize the pts, 
> then it prepare the rild
> enviroment and set its status to start. The init process take the 
> enviroment variable and see that
> it's change and start the rild. The rild open the pseudo terminal and 
> it has no problem.

Init starts your mux. The mux starts and gets interrupted. init knows 
mux is up and starts rild. mux hasn't set property yet. rild runs and 
looks at property which isn't set. This is a race condition. Doesn't 
always happen like that but it can. You cannot control it with the 
status. That property isn't set by your mux. It is set by init. Maybe 
you can have another property of your own you set that init keys off. 
I'm not sure if init is monitoring all property settings or not. But the 
property has to be set after the ptmx call and the rild property has 
been set. Otherwise you cannot be certain it is set before rild starts.

It still doesn't solve the issue of recovery if rild closes the pts. I'm 
pretty sure it will be invalid after that.