Module Name: src
Committed By: pgoyette
Date: Sat Jan 14 21:18:40 UTC 2017
Modified Files:
src/doc: TODO.modules
Log Message:
Add an entry to discuss association of a kernel with its specific modules.
Prompted by recent Email discussion started by wiz (there have been many
earlier discussions on this topic, too).
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/doc/TODO.modules
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/doc/TODO.modules
diff -u src/doc/TODO.modules:1.9 src/doc/TODO.modules:1.10
--- src/doc/TODO.modules:1.9 Thu Dec 15 03:24:43 2016
+++ src/doc/TODO.modules Sat Jan 14 21:18:40 2017
@@ -1,4 +1,4 @@
-/* $NetBSD: TODO.modules,v 1.9 2016/12/15 03:24:43 pgoyette Exp $ */
+/* $NetBSD: TODO.modules,v 1.10 2017/01/14 21:18:40 pgoyette Exp $ */
Some notes on the limitations of our current (as of 7.99.35) module
subsystem. This list was triggered by an Email exchange between
@@ -120,3 +120,13 @@ christos and pgoyette.
select which modules to build and which modules from modules/mi to
include in the release. (This is not limited to PCI; recently we
encounter similar issues with spkr aka spkr_synth module.)
+
+14. As has been pointed out more than once, the current method of storing
+ modules in a version-specific subdirectory of /stand is sub-optimal
+ and leads to much difficulty and/or confusion. A better mechanism of
+ associating a kernel and its modules needs to be developed. Some
+ have suggested having a top-level directory (say, /netbsd) with a
+ kernel and its modules at /netbsd/kernel and /netbsd/modules/...
+ Whatever new mechanism we arrive at will probably require changes to
+ installation procedures and bootstrap code, and will need to handle
+ both the new and old mechanisms for compatability.
