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. > 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. > 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. > 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. > 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). Nicolas
