Re: RFC: poky-tiny: init procedure

[Darren Hart <dvhart@linux.intel.com>]

On 06/15/2012 02:10 PM, Tim Bird wrote:
> 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).
> 

Does this mean you just don't worry about respawning services? If
the.... I dunno... ambient-light-sensor-daemon crashes, is the user
expected to just reboot the device?

> 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.

So Systemd does great things for deterministic boot with clearly defined
dependencies between services which also allows for as much parallelism
as possible (maybe that doesn't matter for your devices). I haven't
looked at how big systemd is what how much it would bloat my kernel to
support it. Have you?

As I understand it, it brings in things like udev and basically starts
to make my system look like a desktop/server. systemd-tiny ftw!

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel