[yocto] RFC: poky-tiny: init procedure

[Darren Hart]

On 06/13/2012 06:09 PM, Tim Bird wrote:
> 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.

I like the rc.local idea as that makes it easily extendable without even
having to modify the original distro definition.

Excellent suggestions, thank you!

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