I would appreciate any donations. Wishlist or send e-mail type donations to maekawa AT daemon-systems.org.

Thank you.


RUMP(3)                    Library Functions Manual                    RUMP(3)

NAME
     rump -- Rump Kernel

LIBRARY
     rump Library (librump, -lrump)

SYNOPSIS
     #include <rump/rump.h>

DESCRIPTION
     A rump kernel is a virtualized kernel instance which retains only part of
     the NetBSD kernel.  Rump kernels are aimed at virtualizing kernel drivers
     and do not support for example creating processes, managing virtual
     memory address spaces or scheduling threads.  These features are
     unnecessary overhead when virtualizing drivers.  Rump kernels are created
     by linking a desired set of components together.  On NetBSD, these
     components are available as userspace libraries with the prefix librump.
     The high-level rumpuser(3) hypercall interface is used by a rump kernel
     to request resources and services from the host it runs on.  Like any
     virtualized kernel, a rump kernel also 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.

     Since a rump kernel does not provide support for applications processes,
     existing entities are used as rump kernel clients.  The relationship
     between the client and the rump kernel defines the execution model of the
     rump kernel.  A local client will reside in the same address space and
     manipulate the rump kernel with function calls and direct memory
     references.  Remote and microkernel clients are disjoint from the rump
     kernel and make requests though various protocols, see for example
     p2k(3), rump_sp(7), and rumphijack(3).  Remote clients will also work
     over a TCP/IP network, or other similar communication medium.

     A rump kernel is bootstrapped by calling rump_init().  On a POSIX Host,
     environment variables can be used to adjust some operating parameters:

     RUMP_NCPU        If set, the number indicates the number of virtual CPUs
                      configured into a rump kernel.  The special value "host"
                      can be used to specify the number of of host CPUs
                      available.  If the value is unset, two CPUs will be
                      configured.

     RUMP_VERBOSE     If set to non-zero, activates bootverbose.

     RUMP_THREADS     If set to 0, prevents the rump kernel from creating any
                      kernel threads.  This is possible usually only for file
                      systems, as other subsystems depend on threads to work.

     RUMP_MEMLIMIT    If set, indicates the maximum amount of memory that a
                      rump kernel will request from the hypervisor via
                      rumpuser_malloc().  When the rump kernel is close to the
                      allocation limit, it will attempt to make more memory
                      available by flushing its caches.  The default is as
                      much as the host allows.

     RUMP_NVNODES     Sets the value of the kern.maxvnodes sysctl node to the
                      indicated amount.  Adjusting this may be useful for
                      example when testing vnode reclaim code paths.  While
                      the same value can be set by means of sysctl, the env
                      variable is often more convenient for quick testing.  As
                      expected, this option has effect only in rump kernels
                      which support VFS.  The current default is 1024 vnodes.

     The standardized way for a client to make requests into a rump kernel is
     to use rump kernel system calls, which have equivalent syntax and
     semantics with regular NetBSD system calls.  The parameters are expected
     to be in the NetBSD type system unless a system call translation
     component, for example librumpkern_sys_linux, is linked into the rump
     kernel, in which case system call parameters will be automatically
     translated from the client type system into the NetBSD type system and
     back.  The rump kernel system calls are made available to a client by
     including <rump/rump_syscalls.h>.  It is also possible to configure
     unmodified binaries to make syscalls into a rump kernel with
     rumphijack(3).

SEE ALSO
     rump_server(1), p2k(3), rump_etfs(3), rump_lwproc(3), rumpclient(3),
     rumphijack(3), rumpuser(3), ukfs(3), rump_sp(7)

     Antti Kantee, "Flexible Operating System Internals: The Design and
     Implementation of the Anykernel and Rump Kernerls", Aalto University
     Doctoral Dissertations, 2012.

     Antti Kantee, "Rump File Systems: Kernel Code Reborn", Proceedings of the
     2009 USENIX Annual Technical Conference, pp. 201-214, June 2009.

     Arnaud Ysmal and Antti Kantee, "Fs-utils: File Systems Access Tools for
     Userland", EuroBSDCon 2009, September 2009.

     Antti Kantee, "Environmental Independence: BSD Kernel TCP/IP in
     Userspace", Proceedings of AsiaBSDCon 2009, pp. 71-80, March 2009.

     Antti Kantee, "Rump Device Drivers: Shine On You Kernel Diamond",
     Proceedings of AsiaBSDCon 2010, pp. 75-84, March 2010.

     Antti Kantee, "Kernel Development in Userspace - The Rump Approach",
     BSDCan 2009, May 2009.

     Web page with more information, including links to the publications:
     http://www.NetBSD.org/docs/rump/

HISTORY
     Rump kernels appeared as an experimental concept in NetBSD 5.0.  The
     first stable version was released in NetBSD 6.0.

AUTHORS
     Antti Kantee <pooka@iki.fi>

NetBSD 7.1.2                     July 14, 2013                    NetBSD 7.1.2