Dear NetBSD users,
The NetBSD core group has discussed the questions presented to us
about the situation with modules and modular kernels.
We understand that there are problems with modularization on all
the platforms, specially on amd64, and we have seen a lot of
breakage due to them in the past years. As core we believe that
ultimately the ability to build modular kernels is the way to go
and that by reverting a lot of the modularization on head we limit
its testing making it harder to become mainstream. On the other
hand, we should always provide a safe way for people to build and
release kernels.
On the positive side:
- Modules can speed up kernel development because they eliminate
many reboots by simply loading and unloading the module during
each development cycle.
- Modules can conserve kernel memory in memory shortage
situations.
- Modules can be used to add/remove/replace functionality on the
fly.
On the negative side:
- Many of our modules are half baked (don't work correctly as
modules, don't specify the right dependencies, or cannot be
unloaded).
- Our module separation is not good (try compiling a kernel with
only COMPAT_30 and all the rest of the compat code as modules;
for now all that works is the all or nothing approach).
- Modules don't work on all platforms. Some platforms don't have a
need for them because their hardware is fixed, but modules could
still be used for software features (compat code, emulations).
- We don't have an easy way to group a kernel and its associated
modules together, so that it's possible to have multiple
bootable kernels, and multiple associated sets of modules, even
if the kernels all share the same version number.
- We don't have a stable kernel ABI so that modules are reusable
across different kernel versions.
- We don't have a way to tell from the kernel config file whether a
feature can be used in a module form or not. (Perhaps comments or
additional config(1) syntax could be used for this.)
Accordingly, we propose the following policy for the immediate
future. We expect that it will be appropriate to re-evaluate this
policy as the state of modular support changes later.
- All ports using modules should provide all three of MODULAR,
MONOLITHIC, and GENERIC kernels.
- At the portmaster's discretion, "options MODULAR" may be made the
default by adding it to the port's "std.<machine>" configuration
file. (A kernel without the "MODULAR" option cannot load any
modules, not even through the modload(8) command.)
- A port's MONOLITHIC kernel should include features that
traditionally would have been present in a non-modular GENERIC
kernel, and it may or may not include "options MODULAR", at the
portmaster's discretion.
- A port's MODULAR kernel may lack many built-in features, expecting
them to be loaded from modules at run time. However, all features
that are necessary for the standard MODULAR kernel to boot and
work reasonably must be built-in. This includes:
* common file systems, including all file systems that can
be the root file system, and also including nullfs and tmpfs;
* disk devices that can contain the root file system;
* common network devices;
* exec support for the native ELF format, and for scripts
(not necessarily for a.out, ECOFF, or compat formats);
* core dump support.
Users or developers may of course comment out relevant lines
if they want to load these items as modules.
- The GENERIC kernel should be based on either MODULAR or
MONOLITHIC, using an "include" directive. The GENERIC kernel
should include "options MODULAR", even if it it based on a
MONOLITHIC kernel that does not include "options MODULAR.
- A port may not set GENERIC = MODULAR if it lacks an easy way to
group a kernel and its associated modules together. Because
no existing ports have this feature, no existing ports may set
GENERIC = MODULAR.
Alan Barrett
On behalf of the NetBSD core group
