All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Michael 'Mickey' Lauer <mickey@vanille-media.de>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Cleaning up service handling in OE
Date: Mon, 23 Apr 2007 10:29:32 +0300	[thread overview]
Message-ID: <7010026723.20070423102932@gmail.com> (raw)
In-Reply-To: <1771542973.20070410132539@vanille-media.de>

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@gmail.com




      reply	other threads:[~2007-04-23 12:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 14:39 [RFC] Cleaning up service handling in OE Paul Sokolovsky
2007-04-06 10:45 ` Paul Sokolovsky
2007-04-08 22:47 ` Tom Walsh
2007-04-10 11:25 ` Michael 'Mickey' Lauer
2007-04-23  7:29   ` Paul Sokolovsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7010026723.20070423102932@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=mickey@vanille-media.de \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.