[src/trunk]: src/doc Add a note regarding the need for a common mechanism for...

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

details:   https://anonhg.NetBSD.org/src/rev/a57f1a63d72b
branches:  trunk
changeset: 355589:a57f1a63d72b
user:      pgoyette <pgoyette%NetBSD.org@localhost>
date:      Fri Aug 04 11:55:06 2017 +0000

description:
Add a note regarding the need for a common mechanism for defining and
building modules, whether built-in or separately-loadable.

diffstat:

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

diffs (21 lines):

diff -r 463cc89dba22 -r a57f1a63d72b doc/TODO.modules
--- a/doc/TODO.modules  Fri Aug 04 09:33:03 2017 +0000
+++ b/doc/TODO.modules  Fri Aug 04 11:55:06 2017 +0000
@@ -1,4 +1,4 @@
-/* $NetBSD: TODO.modules,v 1.11 2017/01/26 04:24:20 pgoyette Exp $ */
+/* $NetBSD: TODO.modules,v 1.12 2017/08/04 11:55:06 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
@@ -135,3 +135,11 @@
     loader time, an alternate value for the os-release portion of the
     default module path,  i.e. /stand/$MACHINE/$ALT-RELEASE/modules/
 
+15. The existing config(5) framework provides an excellent mechanism
+    for managing the content of kernels.  Unfortunately, this mechanism
+    does not apply for modules, and instead we need to manually manage
+    a list of files to include in the module, the set of compiler
+    definitions with which to build those files, and also the set of
+    other modules on which a module depends.  We really need a common
+    mechanism to define and build modules, whether they are included as
+    "built-in" modules or as separately-loadable modules.