The Design and Implementation of the Anykernel and Rump Kernels

132
into a rump kernel and the drivers used. This support allows a rump kernel to use
drivers for which source code is not available. Short of a full virtual machine (e.g.
QEMU), rump kernels are the only form of virtualization in NetBSD capable of
using binary kernel modules without recompilation.
There are two requirements for using binary kernel modules to be possible. First, the
kernel module must not contain any CPU instructions which cannot be executed
in unprivileged mode. As we examined in Section 3.2.2, drivers do not contain
privileged instructions. Second, the rump kernel and the host kernel must share the
same binary interface (ABI).
In practical terms, ABI compatibility means that the rump kernel code does not
provide its own headers to override system headers and therefore all the data type
definitions are the same for a regular kernel and a rump kernel. Problematic scenarios
arise because, mainly due to historical reasons, some architecture specific
kernel interfaces are provided as macros or inline functions. This approach does not
produce a clean interface boundary, as at least part of the implementation is leaked
into the caller. From our perspective, this leakage means that providing an alternate
interface is more difficult.
Shortly before we started investigating kernel module compatibility, some x86 CPU
family headers were changed from inline/macro definitions to function interfaces by
another NetBSD developer. The commit message 13 states that the change was done
to avoid ABI instability issues with kernel modules. This change essentially solved
our problem with inlines and macros. It also reinforced our belief that the anykernel
architecture follows naturally from properly structured code.
A remaining example of macro use in an interface is the pmap interface. The
pmap is the interface to the architecture dependent memory management features.
13 revision 1.146 of sys/arch/i386/include/cpu.h