The Design and Implementation of the Anykernel and Rump Kernels

136
3.8.4 Rump Component Init Routines
In the previous section we discussed the attachment of drivers that followed the
kernel module framework. Now we discuss the runtime attachment of drivers that
have not yet been converted to a kernel module, or code that applies to a only rump
kernel environment.
If a driver is modular, the module’s init routine should be preferred over any rump
kernel specific routines since the module framework is more generic. However, a
module’s init routine is not always enough for a rump kernel. Consider the following
cases. On a regular system, parts of the kernel are configured by userspace
utilities. For example, the Internet address of the loopback interface (127.0.0.1)
is configured by the rc scripts instead of by the kernel. Another example is the
creation of device nodes on the file system under the directory /dev. NetBSDdoes
not have a dynamic device file system and device nodes are pre-created with the
MAKEDEV script. Since a rump kernel does not have an associated userland or a
persistent root file system, these configuration actions must be performed by the
rump kernel itself. A rump component init routine may be created to augment the
module init routine.
By convention, we place the rump component init routines in the component’s source
directory in a file called component.c. To define an init routine, the component
should use the RUMP_COMPONENT() macro. The use of this macro serves the same
purpose as the MODULE() macro and ensures that the init routine is automatically
called during rump kernel bootstrap. The implementation places a descriptor structure
in a .rodata section called rump_components.
The RUMP_COMPONENT() macro takes as arguments a single parameter indicating
when the component should be initialized with respect to other components. This
specifier is required because of interdependencies of components that the NetBSD