[src/trunk]: src/usr.bin/config + pseudo(dev) attach

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

details:   https://anonhg.NetBSD.org/src/rev/d53807ac120f
branches:  trunk
changeset: 339978:d53807ac120f
user:      uebayasi <uebayasi%NetBSD.org@localhost>
date:      Wed Aug 19 03:23:34 2015 +0000

description:
+ pseudo(dev) attach

diffstat:

 usr.bin/config/TODO |  19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diffs (26 lines):

diff -r 0cd7291b2015 -r d53807ac120f usr.bin/config/TODO
--- a/usr.bin/config/TODO       Tue Aug 18 21:26:16 2015 +0000
+++ b/usr.bin/config/TODO       Wed Aug 19 03:23:34 2015 +0000
@@ -285,3 +285,22 @@
   module and its dependencies (selectattr()).  In other words, an option is
   only safely converted to a module (define), only if it doesn't depend on
   anything.  (One example is DDB.)
+
+o Convert pseudo(dev) attach functions to take (void) (== kernel ctors).
+
+  The pseudo attach function was originally designed to take `int n' as
+  the number of instances of the pseudo device.  Now most of pseudo
+  devices have been converted to be `cloneable', meaning that their
+  instances are dynamically allocated at run-time, because guessing how
+  much instances are needed for users at compile time is almost impossible.
+  Restricting such a pure software resource at compile time is senseless,
+  considering that the rest of the world is dynamic.
+
+  If pseudo attach functions once become (void), config(1) no longer
+  has to generate iteration to call those functions, by making them part
+  of kernel constructors, that are a list of (void) functions.
+
+  Some pseudo devices may have dependency/ordering problems, because
+  pseudo attach functions have no choice when to be called.  This could
+  be solved by converting to kctors, where functions are called in order
+  by dependency.