[oe] [RFC] Cleaning up service handling in OE

Paul Sokolovsky pmiscml at gmail.com
Mon Apr 23 07:29:32 UTC 2007


Hello Michael,

Tuesday, April 10, 2007, 2:25:39 PM, you wrote:

> Thanks for raising this issue, Paul.

> The state of the service handling in OE has buggered me since long,
> not just because of the (very valid) points you mentioned, but also
> because of their relationship to sysvinit -- the initscripts are just
> too specialized in my opinion.

> One example: I can see OpenMoko moving to another sysinit scheme,
> most likely upstart. Now how are we (OE) supposed to support that
> while keeping sysinit support updated at the same time.

> We should do it like we support different packaging systems and image
> types -- let me propose going to a more high level description for service
> handling and having a bbclass (INHERIT += sysvinit or INHERIT +=
> upstart) parsing this description and emitting
> the actual init scripts.

        Sorry, I'm not much familiar with alternative startup
managers, so it took me some time to glance over upstart as an
example. So, instead of symlinks to predefined set of dirs, it uses
small file descriptor for each service script, which specifies
parameters, dependencies, etc.

        Then yes, I see what you propose as a good idea. For this, we
would rename update-rc.d.bbclass to sysvinit.bbclass for example (as
its purpose is exactly handling sysvinit's view of things).

        As for specific implementation, I guess this still should
start with adding initial upstart support per se. My guess is that
it's quite probable that we can abstract typical service parameters,
and make specific bbclass implement them in term of some startup
system, but only practice can tell ;-). In worst case, separate
descriptors would need to be written, but at least with
INHERIT += <startup_man>, one needed can be selected by bbclass,
without further specification in .bb.

> What do you think?

> Regards,

> :M:



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com





More information about the Openembedded-devel mailing list