Message-Id: <20180823203747.GU4225@linux.vnet.ibm.com>
Date:   Thu, 23 Aug 2018 13:37:47 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     josh@...htriplett.org, linux-kernel@...r.kernel.org
Subject: Re: Kernel-only deployments?

On Thu, Aug 23, 2018 at 02:42:45PM -0400, Nicolas Pitre wrote:
> On Thu, 23 Aug 2018, Paul E. McKenney wrote:
> 
> > Hello!
> > 
> > Does anyone do kernel-only deployments, for example, setting up an
> > embedded device having a Linux kernel and absolutely no userspace
> > whatsoever?
> 
> Not that I know of.  For one thing, you'd lose the ability to license 
> your application code the way you want.

Good point!  I could see where that might reduce the number of potential
users below the point of usefulness.

> > 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.
> 
> No surprise there.

;-)

> > 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.
> 
> That is possibly still very big. You could probably get away with a 
> statically linked busybox containing only the shell facilities you 
> require for 100K or so.

That does sound considerably more reasonable.

> > 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 still looks big for a custom binary, unless you do have a lot of 
> code in there. It is already possible to have a kernel binary about that 
> size, and even if that's a configured down kernel, quite some complex 
> code remains.
> 
> The bloat might come from the C library you use. It's been a while since 
> glibc stopped caring about not pulling a lot of unneeded code when all 
> you want to do is printf(). It carries all those locale dependencies, 
> etc. You should look at alternative C libs to get things small.

Yes, I really was stupid enough to be using glibc.  Sounds like I have
an easy change to reduce the size further, then.  ;-)

> > 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.
> 
> You could easily do it from your init binary with less trouble than 
> having the kernel carry such an option.

Got it, thank you!

> > So, does anyone in the deep embedded space already do this?
> 
> Not that I know of. Normally, if the init process dies, you typically 
> want the whole system to reboot (you may force a reboot upon any kernel 
> panic for example).

Indeed, your licensing point earlier explains quite a bit.

Thank you again!

							Thanx, Paul

Powered by blists - more mailing lists