On Thu, Sep 23, 2010 at 05:37:38PM -0700, PJ Bostley wrote: > > > > You should write an ofono plugin to properly initialize the 3rd party > > hardware instead. This way, you don't need to start up anything > > manually, get rid of the dependencies, and the ofono plugin can > > actually restart/monitor the service, making your part of the stack > > much more reliable. > We can't. There are other services that must access this hardware also, > and completely independently from ofono. The multiplexing daemon > handles all of that arbitration and startup synchronization.
sure you can... what other services use this hardware as well? You didn't mention this before. the more I hear the more I get the idea that all of this is designed terribly wrong. Why could this not be implemented as a proper kernel driver that allows concurrent access? Is this daemon handling startup synchronization? Did you reimplement one of the existing systems (sysvinit etc.) inside it? Could the other services not also access the hardware through a properly implemented ofonod stack? > > What if your hardware isn't available to the system before ofonod starts? > this piece of hardware is available before the CPU even comes out of > reset.. non-issue.. that's a nonsense answer. Your hardware is damn well not accessible by software when the CPU is resetting. Please answer the question? > > With delayed device initialization, this may very well be the case. > > What if your daemon needs to be restarted? > "/etc/init.d/foo restart" would be handy. tho your now dealing with > broken sockets in a dozen places. What if ofono needs to be restarted? ofono itself never needs a reset because it's designed fairly decent. In case ofono dies accidentally, dbus-activation will restart it automatically, just like a properly designed subsystem should. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
