core's decision on modular kernels

[Alan Barrett <apb%netbsd.org@localhost>]

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