April 27, 2010 posted by Antti Kantee
Since early 2009 NetBSD and rump has supported execution of stock kernel
module binaries in userspace on x86 architectures. Starting in -current as of today, kernel modules will automatically
be loaded from the host into the rump kernel. For example, when mounting a file system in a rump
kernel, support will be automatically loaded before mounting is attempted.
The first issue with autoloading host kernel modules in rump was kernel symbol renaming: to prevent collisions
between the application and kernel C symbols, the rump build uses objcopy to prefix symbols with the string
rumpns. While running objcopy on a prebuilt kernel module was possible without access to the module's source code,
it was a manual step necessary to get a standard kernel module loaded. This was solved by adding a hook
to the module loader to adjust the module's string table after it is loaded but before it is linked.
The second issue was that kernel modules had to be loaded manually by calling rump_sys_modctl(); in contrast
kernel modules are commonly autoloaded when necessary. While the standard kernel routines included in a rump kernel
would attempt to autoload the module, they would fail because the module files were not available within the rump file
system namespace. With some improvements to the rump host file system, etfs, it is now possible to map the kernel
module directory (e.g. /stand/i386/5.99.27/modules) inside the rump kernel.
Autoloading kernel modules from the host demonstrates a key feature and difference of rump-style lightweight service virtualization: only one full host
installation is necessary (although the coexistence of multiple different rump kernel versions is of course possible).
This should be contrasted with traditional heavyweight approaches to building virtual services, where each virtual service
requires an entire OS installation and maintenance.