[src/trunk]: src/doc Add an entry to discuss association of a kernel with its...

[pgoyette <pgoyette%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/8196405dd77f
branches:  trunk
changeset: 820773:8196405dd77f
user:      pgoyette <pgoyette%NetBSD.org@localhost>
date:      Sat Jan 14 21:18:40 2017 +0000

description:
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).

diffstat:

 doc/TODO.modules |  12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diffs (23 lines):

diff -r 6f2514f53643 -r 8196405dd77f doc/TODO.modules
--- a/doc/TODO.modules  Sat Jan 14 21:08:17 2017 +0000
+++ b/doc/TODO.modules  Sat Jan 14 21:18:40 2017 +0000
@@ -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 @@
     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.