(removed openmoko-kernel as it isn't a kernel issue)
Michael Trimarchi wrote:
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.
I'd suggest you name is something else. It is close to the init control
which is ctl.process_name. Sorry for the confusion as I'd assumed that
was what you were keying off.
It still doesn't solve rild resetting (which happens a lot from my
experience).
Anyway, the ril implementation we have it much better with the mux
incorporated and will be released at some point. Complete with working
gprs. Sorry you can't wait and have done your own implementation. TI
also has an implementation close to yours that has the startup issues
I've mentioned as well as the other ones you still have. Theirs is in
the omapzoom repo.
Cheers,
Sean
_______________________________________________
android-freerunner mailing list
[email protected]
http://android.koolu.org/listinfo.cgi/android-freerunner-koolu.org
