Core statement on directory naming for kernel modules

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

Core statement on directory naming for kernel modules -- July 2012

The NetBSD core group has noted concerns about the name of the
directory used for kernel modules.

At present, the kernel loads modules from the
directory /stand/${MODULE_MACHINE}/${VERSION}/modules
(e.g. /stand/amd64/6.99.4/modules).

There have been several objections to this use of the /stand directory,
and several suggestions for alternatives.  On 8 July 2012, David Holland
presented this summary of the proposals, and objections to them:

   /boot is wrong because modules are not used only or even primarily at boot.

   /lib/modules is wrong because modules are not link libraries.

   /libdata/modules is wrong because modules are not data.

   /libexec/modules is wrong because modules are not programs.

   /modules is wrong because it adds a new toplevel directory.

   /stand/modules is wrong because modules are not used without the kernel.

There have also been proposals for more radical changes, including:

   Keeping both the kernel and its modules together in a directory.
   A detailed description was posted by Luke Mewburn
   <http://mail-index.NetBSD.org/current-users/2009/05/10/msg009372.html>.

   Keeping both the kernel and its modules together in a tar archive.

   Keeping both the kernel and its modules together in an ELF executable.

The core group is of the opinion that it is too late for such major
changes to be included in NetBSD-6.  Accordingly, we think that the
existing scheme should be retained, without changes to either directory
names or more fundamental aspects, for the NetBSD-6 release.  Changes to
either the directory names, or more fundamental aspects of the scheme,
or both, may be made in the future.

The core group would also like to see the following changes in the near
future:

   Implementation of the scheme described by Luke Mewburn in
   <http://mail-index.NetBSD.org/current-users/2009/05/10/msg009372.html>
   to allow a kernel and its modules to be kept together.

   Changes to config(1) to extend the existing notion of whether or not
   an option is built-in to the kernel, to three states: built-in, not
   built-in but loadable as a module, entirely excluded and not even
   loadable as a module.

Alan Barrett, on behalf of core