RUMP(3)                 NetBSD 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 mem-
     ory 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 refer-
     ences.  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 avail-
                      able.  If the value is unset, two CPUs will be config-
                      ured.

     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 seman-
     tics 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 6.0                       July 14, 2013                      NetBSD 6.0

You can also request any man page by name and (optionally) by section:

Command: 
Section: 
Architecture: 
Collection: 
 

Use the DEFAULT collection to view manual pages for third-party software.


©1994 Man-cgi 1.15, Panagiotis Christias <christia@softlab.ntua.gr>
©1996-2014 Modified for NetBSD by Kimmo Suominen