gsmd / libgsmd robustness

Koen Kooi koen at dominion.kabel.utwente.nl
Wed Aug 29 11:08:10 CEST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexandre d'Alton schreef:
> 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.

wow, one dependency on libdbus1 turns into "lot of dependancy on system libraries". with
dbus you go from 2 (libc6 and libgcc) to 3 (libc6, libgcc and libdbus). Does that warrant
all the FUD and ugly hacks you are planning? I suspect harald hasn't even *looked* at dbus
before starting his FUD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG1Td6MkyGM64RGpERArF/AJ0RAmJa6zGumRgIaTvDxELzBfhqNQCglrMv
4LjcVNs0qnKmw5t8uPpaAwU=
=fMqi
-----END PGP SIGNATURE-----




More information about the gsmd-devel mailing list