gsmd / libgsmd robustness

Alexandre d'Alton moko at alexdalton.org
Wed Aug 29 10:48:10 CEST 2007


Hi Harald,

I'm trying to find some solutions in order to allow the gsmd to be
restarted without the need of re-starting the client applications.

Up to now, I've done different things that seems to make the startup
cleaner and robust on gsmd restart. I don't think this is a good solution,
but I want to explain it in order to give ideas and have comments.

1- In the gsmd init script, I sleep a few more seconds before starting gsmd
from modem power-up.

2- In the libmokogsmd library, I've added a semaphore in order to prevent
two different applications to stop/start gsmd without sync. There were a
problem for example when both panel-gsm and dialer were failing in libgsmd
initialisation leading for one to stop/start gsmd and then the other one
doing the same, ending up with the first application not having a valid
handle to gsmd as it were re-started by the second application. I've
initialized the semaphore in the xserver-nodm init script (not a good place
IMO).

3- In one libmokogsmd request call, if the connection to gsmd were broken,
I re-start the connection by calling lgsm_init again in order to allow
application to re-connect if gsmd were re-started.

These changes allow my phone the start well in a cold boot, and also allows
the gsmd to be restarted without causing applications to fail using libgsm.


This leads to the following proposal:

Can we allow all libgsmd functions to check the validity of the gsmd
handles on each requests and to re-create that handle in case of invalid
handle (in case of gsmd restart). That would allow applications/libmokogsmd
 not to re-trigger the lgsm_init if there were an error.

we would need to add a kind of callback in order to notify the application
that the handle (fd) has changed in order to allow it to re-create the
listener on that handle, and to trigger necessary code that would have the
purpose of updating the state of the modem accordingly.

That way, we can have a little daemon that monitors the presence of the
gsmd process in order to re-start it when it fails transparently without
breaking any libgsmd applications.

We'll also need a way of making the applications blocks until the gsmd is
restarted in order to avoid the problem described above.

What do you think about that proposal ?

I've also read some comments on switching the unix socket ipc to dbus that
would also solve this problem. I also read that you're not supporting that
idea, and I must addmit that I agree that libgsmd and gsmd shall not have a
lot of dependancy on system libraries.

Do you have some plans or do you have started some developments in order to
solve these problems or is it ok for me to try implementing my solution and
contribute it ?

Thanks,

Alex.




More information about the gsmd-devel mailing list