The Design and Implementation of the Anykernel and Rump Kernels

70
for loadable kernel modules (discussed further in Section 3.8.1). Originally, the file
contained routines both for loading kernel modules from the file system and for
keeping track of them. Having both in one module was a valid possibility before the
anykernel faction model. In the anykernel model, loading modules from a file system
is VFS functionality, while keeping track of the modules is base functionality.
To make the code comply with the anykernel model, we used the code moving
technique to move all code related to file system access to its own source file in
kern_module_vfs.c. Since loading from a file system must still be initiated by the
kernel module management routines, we introduced a function pointer interface. By
default, it is initialized to a stub:
int (*module_load_vfs_vec)(const char *, int, bool, module_t *,
prop_dictionary_t *) = (void *)eopnotsupp;
If VFS is present, the routine module_load_vfs_init() is called during VFS subsystem
init after the vfs_mountroot() routine has successfully completed to set
the value of the function pointer to module_load_vfs(). In addition to avoiding a
direct reference from the base to a faction in rump kernels, this pointer has another
benefit: during bootstrap it protects the kernel from accidentally trying to load
kernel modules from the file system before a file system has been mounted 3 .
3.1.1 Extracting and Implementing
We have two methods for providing functionality in the rump kernel: we can extract
it out of the kernel sources, meaning we use the source file as such, or we can
implement it, meaning that we do an implementation suitable for use in a rump
3 sys/kern/vfs_subr.c rev 1.401