NAME
rump kernel —
The Anykernel and Rump
Kernels
DESCRIPTION
Rump kernels provide portable, componentized, kernel quality drivers such as
file systems, POSIX system call handlers, PCI device drivers, a SCSI protocol
stack, virtio and a TCP/IP stack. The fundamental enabling technology is the
anykernel architecture of
NetBSD, which enables the
use of unmodified
NetBSD kernel drivers. The
minimalistic
rumpuser(3)
interface integrates a rump kernel to the host platform. Suitable and readily
supported platforms include for example POSIX userspace (such as
NetBSD), hypervisors (such as Xen and KVM), and bare
metal hardware.
Rump kernels are component-oriented, which means that they consist of libraries
which are linked together to form runtime images. If the platform supports it,
dynamic linking may be used to load components at runtime, allowing the
creation of services where the runtime component configuration is specified
when the service is run (see
rump_server(1) for an
example).
A rump kernel provides its own set of namespaces, such as a file system
hierarchy and TCP ports, that are independent of the ones on the host and of
any other rump kernel instances. It should be noted that the presence of the
provided namespaces depends on the components that the rump kernel was
constructed with. For example, networking and file systems are components, and
it is possible to construct a rump kernel which supports neither.
A rump kernel accepts the following bootstrap parameters. The exact way of
specifying the parameters depends on the host platform; for example in POSIX
userspace the parameters are environment variables.
-
-
RUMP_NCPU
- If set, the value indicates the number of virtual cores
configured into a rump kernel, i.e. the number of threads which can be
concurrently executing code inside the rump kernel.
The special value "host" can be used to specify the number of of
host cores available (note: not available on all platforms). If this
parameter is unset, two cores will be configured.
-
-
RUMP_VERBOSE
- If set to non-zero, causes bootstrap messages to be
displayed on the console.
-
-
RUMP_MEMLIMIT
- If set, indicates the maximum amount of memory that a rump
kernel will attempt to allocate from the host. If this parameter is unset,
the rump kernel attempt to allocate host memory until allocation fails.
When the rump kernel is close to the allocation limit, or when host
allocation fails, the rump kernel will attempt to make more memory
available by invoking its internal pagedaemon to flush caches.
SEE ALSO
http://rumpkernel.org/
Antti Kantee and
Justin Cormack, Rump Kernels: No
OS? No Problem!, USENIX, ;login:,
No. 5, Vol. 39,
October 2014.
Antti Kantee,
Flexible Operating System Internals: The Design and
Implementation of the Anykernel and Rump Kernels, Aalto
University Doctoral Dissertations, 2012.
Antti Kantee, Rump
Device Drivers: Shine On You Kernel Diamond, Proceedings
of AsiaBSDCon 2010, pp. 75-84,
March 2010.
Arnaud Ysmal and
Antti Kantee, Fs-utils: File
Systems Access Tools for Userland, EuroBSDCon 2009,
September 2009.
Antti Kantee, Rump
File Systems: Kernel Code Reborn, Proceedings of the
2009 USENIX Annual Technical Conference, pp.
201-214, June 2009.
Antti Kantee, Kernel
Development in Userspace - The Rump Approach, BSDCan
2009, May 2009.
Antti Kantee,
Environmental Independence: BSD Kernel TCP/IP in
Userspace, Proceedings of AsiaBSDCon 2009,
pp. 71-80, March
2009.
HISTORY
An experimental concept for the anykernel and rump kernels was first seen during
the
NetBSD 5.0 development cycle. A stable concept was
ready for
NetBSD 6.0.