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.
