p 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 .Xr rump_server 1 for an example).
p 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.
p 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. l -tag -width RUMP_MEMLIMITXX t Dv 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.
p 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. t Dv RUMP_VERBOSE If set to non-zero, causes bootstrap messages to be displayed on the console. t Dv 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. .El .Sh SEE ALSO .Lk https://rumpkernel.github.io .Rs .%A Antti Kantee .%A Justin Cormack .%T "Rump Kernels: No OS? No Problem!" .%D October 2014 .%I USENIX .%J ;login: .%N No. 5 .%V Vol. 39 .Re .Rs .%A Antti Kantee .%D 2012 .%J Aalto University Doctoral Dissertations .%T Flexible Operating System Internals: The Design and Implementation of the Anykernel and Rump Kernels .Re .Rs .%A Antti Kantee .%D March 2010 .%B Proceedings of AsiaBSDCon 2010 .%P pp. 75-84 .%T Rump Device Drivers: Shine On You Kernel Diamond .Re .Rs .%A Arnaud Ysmal .%A Antti Kantee .%D September 2009 .%B EuroBSDCon 2009 .%T Fs-utils: File Systems Access Tools for Userland .Re .Rs .%A Antti Kantee .%D June 2009 .%B Proceedings of the 2009 USENIX Annual Technical Conference .%P pp. 201-214 .%T Rump File Systems: Kernel Code Reborn .Re .Rs .%A Antti Kantee .%D May 2009 .%B BSDCan 2009 .%T Kernel Development in Userspace - The Rump Approach .Re .Rs .%A Antti Kantee .%D March 2009 .%B Proceedings of AsiaBSDCon 2009 .%P pp. 71-80 .%T Environmental Independence: BSD Kernel TCP/IP in Userspace .Re .Sh HISTORY An experimental concept for the anykernel and rump kernels was first seen during the .Nx 5.0 development cycle. A stable concept was ready for .Nx 6.0 .