[src/trunk]: src/doc Note desire to have a way to selectively build modules (...

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

details:   https://anonhg.NetBSD.org/src/rev/ba2f049b7cd1
branches:  trunk
changeset: 349569:ba2f049b7cd1
user:      pgoyette <pgoyette%NetBSD.org@localhost>
date:      Thu Dec 15 03:24:43 2016 +0000

description:
Note desire to have a way to selectively build modules (and include them
from the modules/mi sets-list) based on "attributes" rather than having
to enumerate individual architectures on which to build and include.

diffstat:

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

diffs (24 lines):

diff -r 7e6120c9639e -r ba2f049b7cd1 doc/TODO.modules
--- a/doc/TODO.modules  Thu Dec 15 02:43:56 2016 +0000
+++ b/doc/TODO.modules  Thu Dec 15 03:24:43 2016 +0000
@@ -1,4 +1,4 @@
-/* $NetBSD: TODO.modules,v 1.8 2016/09/28 06:47:55 wiz Exp $ */
+/* $NetBSD: TODO.modules,v 1.9 2016/12/15 03:24:43 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
@@ -109,3 +109,14 @@
 
 12. Item #11 gets even murkier when a particular parent can provide more
     than one attribute.
+
+13. It seems that we might want some additional sets-lists "attributes"
+    to control contents of distributions.  As an example, many of our
+    architectures have PCI bus capabilities, but not all.  It is rather
+    painful to need to maintain individual architectures' modules/md_*
+    sets lists, especially when we already have to conditionalize the
+    build of the modules based on architecture.  If we had a single
+    "attribute" for PCI-bus-capable, the same attribute could be used to
+    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.)