All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ray Clinton <mr.ray.clinton@gmail.com>
To: paulmck@linux.vnet.ibm.com
Cc: nicolas.pitre@linaro.org, josh@joshtriplett.org,
	linux-kernel@vger.kernel.org
Subject: Re: Kernel-only deployments?
Date: Thu, 23 Aug 2018 15:22:48 -0400	[thread overview]
Message-ID: <CAPMnawvzuAaXmuMg_Z4_Av59zHmxeWzdbfZv3GaX6Vmw48t+Aw@mail.gmail.com> (raw)
In-Reply-To: <20180823174359.GA13033@linux.vnet.ibm.com>

On Thu, Aug 23, 2018 at 7:44 PM Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> Does anyone do kernel-only deployments, for example, setting up an
> embedded device having a Linux kernel and absolutely no userspace
> whatsoever?

To be honest I'm a total newb to kernel dev, so much so that I copied and
pasted the above quote in the hopes that I did the formatting right. I'm such
 a newb that I realize I might not even understand your question.

That beingsaid, wouldn't building a uImage of the kernel and loading it onto
your device using tftpboot accomplish this?

Ray On Thu, Aug 23, 2018 at 1:46 PM Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
>
> 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!!!
>

  parent reply	other threads:[~2018-08-23 19:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 17:43 Kernel-only deployments? Paul E. McKenney
2018-08-23 18:16 ` 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 [this message]
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=CAPMnawvzuAaXmuMg_Z4_Av59zHmxeWzdbfZv3GaX6Vmw48t+Aw@mail.gmail.com \
    --to=mr.ray.clinton@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /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.