Module Name: src
Committed By: pgoyette
Date: Thu Dec 15 03:24:43 UTC 2016
Modified Files:
src/doc: TODO.modules
Log Message:
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.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 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.8 src/doc/TODO.modules:1.9
--- src/doc/TODO.modules:1.8 Wed Sep 28 06:47:55 2016
+++ src/doc/TODO.modules Thu Dec 15 03:24:43 2016
@@ -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 @@ christos and pgoyette.
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.)
