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 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
