Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <d47f1f4b828e6099c7db2ca4a4728536b3ad2723.camel@petrovitsch.priv.at>
Subject: Re: Kernel-only deployments?
From:   Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To:     paulmck@linux.vnet.ibm.com, nicolas.pitre@linaro.org,
        josh@joshtriplett.org
Cc:     linux-kernel@vger.kernel.org
Date:   Thu, 23 Aug 2018 21:52:17 +0200
In-Reply-To: <20180823174359.GA13033@linux.vnet.ibm.com>
References: <20180823174359.GA13033@linux.vnet.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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:

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).

[...]
> 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 ...

> 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 ....

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).

[...]

MfG,
	Bernd

[0]: Every byte counts and size does matter;-)
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at