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
