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;
Date:   Thu, 23 Aug 2018 10:43:59 -0700
From:   "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To:     nicolas.pitre@linaro.org, josh@joshtriplett.org
Cc:     linux-kernel@vger.kernel.org
Subject: Kernel-only deployments?
Reply-To: paulmck@linux.vnet.ibm.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20180823174359.GA13033@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello!

Does anyone do kernel-only deployments, for example, setting up an
embedded device having a Linux kernel and absolutely no userspace
whatsoever?

The reason I as is that such a mode would be mildly useful for rcutorture.

You see, rcutorture runs entirely out of initrd, never mounting a real
root partition.  The user has been required to supply the initrd, but
more people are starting to use rcutorture.  This has led to confusion
and complaints about the need to supply the initrd.  So I am finally
getting my rcutorture initrd act together, with significant dracut help
from Connor Shu.  I added mkinitramfs support for environments such as
mine that don't support dracut, at least not without significant slashing
and burning.

The mkinitramfs approach results in about 40MB of initrd, and dracut
about 10MB.  Most of this is completely useless for rcutorture, which
isn't interested in mounting filesystems, opening devices, and almost
all of the other interesting things that mkinitramfs and dracut enable.

Those who know me will not be at all surprised to learn that I went
overboard making the resulting initrd as small as possible.  I started
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.
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.
This is a great improvement over 10MB, to say nothing of 40MB, but 800KB
for a C-language "for" loop containing nothing more than a single call to
sleep()?  Much of the code is there for things that I might do (dl_open(),
for example), but don't.  All I can say is that there clearly aren't many
of us left who made heavy use of systems with naked-eye-visible bits!
(Or naked-finger-feelable, for that matter.)

This further prompted the idea of modifying kernel_init() to just loop
forever, perhaps not even reaping orphaned zombies [*], given an appropriate
Kconfig option and/or kernel boot parameter.  I obviously cannot justify
this to save a sub-one-megabyte initrd for rcutorture, no matter how much
a wasted 800K might have offended my 30-years-ago self.  If I take this
next step, there have to be quite a few others benefiting significantly
from it.

So, does anyone in the deep embedded space already do this?

							Thanx, Paul

[*]	What zombies???  There is no userspace!!!