[yocto] RFC: poky-tiny: init procedure

[Tim Bird]

On 6/13/2012 5:33 PM, Darren Hart wrote:
> For those of you using poky-tiny or are interested in building very very
> small systems, I would appreciate your thoughts here.
>
> Currently poky-tiny images will boot and run /bin/sh, which results in
> error messages to the console about being unable to open the tty and job
> control being disabled (this is a common problem, if not commonly
> understood).
>
> The shell must be session leader to open the tty, and the tty must not
> be /dev/console (it should be a vt or a physical tty like ttyS0), the
> tty is required for job control (handling signals, etc.).
>
> The Problem:
> poky-tiny should boot to a shell without error messages and have
> job-control.
>
> The Vision:
> The goals of poky-tiny are to be an initial starting point from which to
> build a distribution that does what you want, and NOTHING more.
>
> The Proposal:
> o Do not include the standard Busybox init
> o Do provide a basic /init script that can be easily modified
> o Do provide a basic shell
>    o Without init, this requires setsid and cttyhack to easily find the
>      right device
> o Do not provide inittab functionality
>
> I can accomplish this by updating busybox to include:
> CONFIG_SETSID=y
> CONFIG_CTTYHACK=y
>
> And providing a basic init script as follows:
>
> #!/bin/sh
> mount none -t proc /proc
> mount none -t sysfs /sys
> mkdir /dev/pts
> mount none -t devpts /dev/pts
> ifup lo
>
> # Become session leader and try to find a real tty (e.g. ttyS0)
> setsid cttyhack sh
>
> This results in a system that boots with the virtual filesystems
> mounted, the local network interface up, and a shell with job control
> running. Nothing else.
>
> Potential Problems:
> Should the script be /init (for initramfs images) or /sbin/init for
> images on block devices. Note that the default method of running
> poky-tiny is with an initramfs as it doesn't support any block devices
> by default.
>
> Adding services like dropbear to your image will not get started on boot
> as their init scripts will not be run. I'm OK with documenting this
> behavior as part of creating your own distribution based on tiny.
>
> If the shell crashes, or you exit, the kernel panics (because init returns).
>
> Thoughts/Comments/Criticism welcome.
>

This sounds like a great approach.  What I've found at Sony is that it's 
nice to
have a template for turning on individual services, that users can 
decide to enable or not.
You don't want to include everything under the sun, but it's nice to 
have a few basic
things spelled out (but disabled) so that users can easily enable them.

How about adding something like:
if [ -f /etc/rc.local ] ; then
  exec /etc/rc.local
fi

You could have this be as is, or the lines could be commented out.

Inside /etc/rc.local you have a bunch of commented-out lines for turning on
services like telnetd, dropbear, mounting debugfs, starting networking 
(ifup eth0),
etc.  If the user wants any of these individual items, they uncomment the
appropriate lines in /etc/rc.local.

IMHO, you DON'T want to create some fancy directory-based system like 
sysVinit
that automatically handles anything that could possibly be included.  But
having a couple of common cases that the user can easily enable is 
pretty handy.

Alternatively, you could have these commented-out lines in the init 
script itself.
This saves you an additional file in the rootfs, as well as the fork to exec
/etc/rc.local.  (I suppose you could also 'source' this, to avoid the fork.)

Just some ideas.
  -- Tim