All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: RFC: poky-tiny: init procedure
Date: Wed, 13 Jun 2012 19:55:31 -0700	[thread overview]
Message-ID: <4FD952A3.7080306@linux.intel.com> (raw)
In-Reply-To: <4FD93C71.1080004@linux.intel.com>



On 06/13/2012 06:20 PM, Darren Hart wrote:
> 
> 
> 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!
> 

Updated init with Tim's recommendations and a loop to avoid the kernel
panic on shell exit:

#!/bin/sh

# Mount the Linux kernel virtual filesystems
mount none -t proc /proc
mount none -t sysfs /sys
mkdir /dev/pts
mount none -t devpts /dev/pts

ifup lo

# Allow for distro or local customizations
if [ -f /etc/rc.local ] ; then
        source /etc/rc.local
fi

# Become session leader and try to find a real tty (e.g. ttyS0)
while true; do
        setsid cttyhack sh
        echo "Console sh exited with $?, respawning..."
        sleep 1
done


I believe this is a reasonable set of things to expect to be working on
ANY system built with the Yocto Project (currently poky-tiny is defined
in meta-yocto).

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




  reply	other threads:[~2012-06-14  2:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14  0:33 RFC: poky-tiny: init procedure Darren Hart
2012-06-14  1:09 ` Tim Bird
2012-06-14  1:20   ` Darren Hart
2012-06-14  2:55     ` Darren Hart [this message]
2012-06-14  7:11 ` Tomas Frydrych
2012-06-14 21:09   ` Darren Hart
2012-06-15  6:31     ` Tomas Frydrych
2012-06-15  7:05       ` Thomas Petazzoni
2012-06-15 23:04         ` Darren Hart
2012-06-15 19:49       ` Tim Bird
2012-06-15 21:26         ` Tomas Frydrych
2012-06-15 23:15           ` Darren Hart
2012-06-16  8:53             ` Tomas Frydrych
2012-06-15 21:10   ` Tim Bird
2012-06-15 23:21     ` Darren Hart
2012-06-18 11:50     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD952A3.7080306@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=tim.bird@am.sony.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.