The Design and Implementation of the Anykernel and Rump Kernels

68
We identified three obstacles for having a partitioned kernel:
1. Compile-time definitions (#ifdef) indicating which features are present
in the kernel. Compile-time definitions are fine within a component, but
do not work between components if linkage dependencies are created (for
example a cross-component call which is conditionally included in the compilation).
2. Direct references between components where we do not allow them. An
example is a reference from the base to a faction.
3. Multiclass source modules contain code which logically belongs in several
components. For example, if the same file contains routines related to both
file systems and networking, it belongs in this problem category.
Since our goal is to change the original monolithic kernel and its characteristics
as little as possible, we wanted to avoid heavy approaches in addressing the above
problems. These approaches include but are not limited to converting interfaces to
be called only via pointer indirection. Instead, we observed that indirect interfaces
were already used on most boundaries (e.g. struct fileops, struct protosw,
etc.) and we could concentrate on the exceptions. Code was divided into functionality
groups using source modules as boundaries.
The three techniques we used to address problems are as follows:
1. code moving. This solved cases where a source module belonged to several
classes. Part of the code was moved to another module. This technique had
to be used sparingly since it is very intrusive toward other developers who
have outstanding changes in their local trees. However, we preferred moving