[yocto] RFC: poky-tiny: init procedure

[Tim Bird]

On 06/14/2012 12:11 AM, Tomas Frydrych wrote:
> A system that runs nothing but a shell is really not useful for anything
> all, everyone using it will be adding some sort of services, so the
> question of how the extending works (or does not work), needs to be in
> the forefront of the design. My main reservation is that you are
> suggesting to break one of the basic premisses behind the whole
> ecosystem, namely that if I add a package that provides a service to an
> image, I get that service running; 'fix by documentation' is never a fix.

I didn't address this in my other response, and I
think it's a valid observation.  I agree that
everyone will want to add something to the init,
and that 'fix by documentation' is, in general, a
poor solution.

I don't have any good solution here (one that scales,
or is likely to be adopted widely.)  You don't really
need documentation, if you have the few lines of shell
script that are necessary to start a service in minimal
mode.  The standard init scripts handle lots of interactions
with other services and runtime conditions.  This is why
they are bloated (and the abstractions in them are
almost incomprehensible to read.)

At Sony we've tried various things - like automatically
stripping init scripts of uncalled branches, removing
conditionals that don't apply, etc.  We've also looked
at automatically converting init scripts to C code, to
speed up execution.  You still end up with gobs of code
that doesn't apply to your situation getting executed
at boot time, an overly-complicated test scenario, and a
certain fragility in the overall init system.

One of our early efforts, getting busybox
to not fork commands in init scripts that it had as
builtins, proved to be a significant feature that is still
valuable today to improve boot time.

What we have settled on as a generic solution is basically
what I described in response to Darren's initial post.
You have a list of the short shell snippets required to start
commonly-used services in /etc/rc.local.  These
are commented out by default, but a developer or product
team can uncomment them to enable the associated services.
This keeps everything in one place and provides developers
the commands needed to start things.  Customization to
handle interactions or special cases can proceed from
there.  It's not ideal, in that a developer may have to
re-create or rediscover some configuration, setting, or
start sequence to handle a more complicated usage scenario.
But in order to hit our targets for size or boot time, it
has been helpful to do things this way.  The developer is
forced to manually enable each service, and the start
sequence, commands and command parameters are obvious
from the script.  (This is rarely true of init scripts).

If anyone has good ideas or other experience for
the init sequence for highly customized,
resource-constrained products, I'd like to hear about
them.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================