vchanneld

[Sean McNeil]

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.

>> 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.
>>
>> Cheers,
>> Sean
>>
>> 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 
>>> multiplexing?
>>>
>>> Michael
>>>
>>
>>
>