All of lore.kernel.org
 help / color / mirror / Atom feed
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?
Date: Thu, 23 Aug 2018 10:43:59 -0700	[thread overview]
Message-ID: <20180823174359.GA13033@linux.vnet.ibm.com> (raw)

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


             reply	other threads:[~2018-08-23 17:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 17:43 Paul E. McKenney [this message]
2018-08-23 18:16 ` Kernel-only deployments? Geert Uytterhoeven
2018-08-23 18:43   ` Paul E. McKenney
2018-08-23 18:42 ` Nicolas Pitre
2018-08-23 20:37   ` Paul E. McKenney
2018-08-23 18:54 ` Adam Borowski
2018-08-23 19:06   ` Willy Tarreau
2023-02-15  2:35     ` Zhangjin Wu
2023-02-15  9:47       ` Willy Tarreau
2023-02-16 13:09         ` Zhangjin Wu
2018-08-23 19:16   ` Josh Triplett
2018-08-23 20:39     ` Paul E. McKenney
2018-08-23 20:39   ` Paul E. McKenney
2018-08-23 19:12 ` Josh Triplett
2018-08-23 20:45   ` Paul E. McKenney
2018-08-23 19:22 ` Ray Clinton
2018-08-23 20:49   ` Paul E. McKenney
2018-08-23 19:52 ` Bernd Petrovitsch
2018-08-23 20:54   ` Paul E. McKenney

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=20180823174359.GA13033@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.pitre@linaro.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.