vchanneld

[Michael Trimarchi]

Hi,

Sean McNeil wrote:
> 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. 
 asprintf(&cmd, "-d %s", vch[1]->ptsname);
 property_set("rild.libargs", cmd);
 property_set(PROPERTY_VCHANNEL_STATUS, "start");
 free(cmd);

I don't think so. The property that you refer is the starting and it is 
set by the init. You can
trigger any process.

Michael