Message-Id: <20180823205448.GZ4225@linux.vnet.ibm.com>
Date:   Thu, 23 Aug 2018 13:54:48 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Bernd Petrovitsch <bernd@...rovitsch.priv.at>
Cc:     nicolas.pitre@...aro.org, josh@...htriplett.org,
        linux-kernel@...r.kernel.org
Subject: Re: Kernel-only deployments?

On Thu, Aug 23, 2018 at 09:52:17PM +0200, Bernd Petrovitsch wrote:
> Hi all!
> 
> On Thu, 2018-08-23 at 10:43 -0700, Paul E. McKenney wrote:
> > [...]
> > Does anyone do kernel-only deployments, for example, setting up an
> > embedded device having a Linux kernel and absolutely no userspace
> > whatsoever?
> [...]
> > You see, rcutorture runs entirely out of initrd, never mounting a real
> > root partition.  The user has been required to supply the initrd, but
> 
> IMHO running programs from the initrd is in user-space, but anyways:

Agreed, rcutorture still has a userspace, albeit a small one.  I was
wondering if I should take the next step and eliminate userspace entirely.
Josh Triplett pointed out that doing so would reduce my test coverage,
so the answer is that I should not eliminate userspace entirely for
rcutorture.

> Ages ago at some former employer, we built an embedded Linux device on
> an MPC-860 board (but that shouldn't make a significant difference to
> other architectures) based on the (at that time) brand new 2.4 kernel
> which ran completely out of the initrd (which obviously contained the
> whole root filesystem).

Cute!  The rcutorture test scripts do something similar, but you
clearly got there long before I did.

> [...]
> > by throwing out everything not absolutely needed by the dash and sleep
> > binaries, which got me down to about 2.5MB, 1.8MB of which was libc.
> 
> We had a working glibc binary (which as the largest binary on the
> filesystem) and just used it (and never got time and/or necessity to
> use something else like ulibc, newlibc or build glibc ourselves to
> leave all unneeded stuff out).
> 
> We basically built the filesystem - the distribution as such;-) - from
> scratch (only self-crafted `configure` calls around[0]) and - thus -
> used busybox and ash (IIRC) - so throw dash, core-utils etc. away and
> just use busybox (or something similar) for further space savings.
> 
> The whole startup and daemon management was done with busybox' "init"
> via a simple /etc/inittab (that were the good old times;-) and it was
> enough as one can start one-time programs at boot time (e.g. to load
> kernel modules (and remove the file in the filesystem from the
> filesystem[0]) or configure stuff via sysctl) and restart daemons. We
> didn't need run-levels ...

Indeed, concerns about possible additional boot-time kernel-userspace
interactions led me to use dracut or mkinitramfs if available, and
hand-craft the "init" binary only if neither was present.

> > This situation of course prompted me to create an initrd containing
> > a statically linked binary named "init" and absolutely nothing else
> > (not even /dev or /tmp directories), which weighs in at not quite 800KB.
> 
> That is probably the smallest solution - if it's enough. If it's all
> GPL, just link it statically against dietlibc ....

Sounds like there are a number of reduced-weight libc libraries
available.

> We had all of the usual directories and a somewhat filled /dev
> (completely static in the initrd IIRC, no udev or similar dynamic stuff
> was needed) as we had dropbear as ssh-server, a small webserver+CGI-
> script for a web interface and a SNMP agent (hacked net-smtp as we had
> our own configuration daemon and needed SNMP only as a transport
> protocol).

Cool!  Me, I currently leave networking out.  I compile it into the
kernel to catch build problems, but don't actually exercise the
networking code.

> [...]
> 
> MfG,
> 	Bernd
> 
> [0]: Every byte counts and size does matter;-)

;-) ;-) ;-)

							Thanx, Paul

> -- 
> Bernd Petrovitsch                  Email : bernd@...rovitsch.priv.at
>                      LUGA : http://www.luga.at
> 

Powered by blists - more mailing lists