Messages in this thread | | | From | Ray Clinton <> | Date | Thu, 23 Aug 2018 15:22:48 -0400 | Subject | Re: Kernel-only deployments? |
| |
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!!! >
| |