Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 23 Aug 2018 13:49:11 -0700
From:   "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To:     Ray Clinton <mr.ray.clinton@gmail.com>
Cc:     nicolas.pitre@linaro.org, josh@joshtriplett.org,
        linux-kernel@vger.kernel.org
Subject: Re: Kernel-only deployments?
Reply-To: paulmck@linux.vnet.ibm.com
References: <20180823174359.GA13033@linux.vnet.ibm.com>
 <CAPMnawvzuAaXmuMg_Z4_Av59zHmxeWzdbfZv3GaX6Vmw48t+Aw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPMnawvzuAaXmuMg_Z4_Av59zHmxeWzdbfZv3GaX6Vmw48t+Aw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20180823204911.GY4225@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 23, 2018 at 03:22:48PM -0400, Ray Clinton wrote:
> 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?

I do something vaguely similar, but instead use qemu, passing it arguments
to grab the kernel from the filesystem.  Here is an example qemu command
generated by the rcutorture scripts:

qemu-system-x86_64 -enable-kvm -nographic -smp 1 -serial file:/home/paulmck/public_git/linux-rcu/tools/testing/selftests/rcutorture/res/2018.08.23-10:22:45/TREE09/console.log -m 512 -kernel /home/paulmck/public_git/linux-rcu/tools/testing/selftests/rcutorture/res/2018.08.23-10:22:45/TREE09/bzImage -append "noapic selinux=0 initcall_debug debug console=ttyS0 rcutorture.n_barrier_cbs=4 rcutorture.stat_interval=15 rcutorture.shutdown_secs=600 rcutorture.test_no_idle_hz=1 rcutorture.verbose=1"

This runs single-threaded, captures console output on a file named
"console.log", provides 512MB of memory, grabs the kernel from the
specified "bzImage" file, and passes in a bunch of kernel parameters.

See tools/testing/selftests/rcutorture in recent Linux-kernel source
trees for more information, should you want more.  ;-)

							Thanx, Paul

> 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!!!
> >
>