[src/trunk]: src/doc Add a list of "module issues" based on an Email discussi...

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

details:   https://anonhg.NetBSD.org/src/rev/641dca727791
branches:  trunk
changeset: 346824:641dca727791
user:      pgoyette <pgoyette%NetBSD.org@localhost>
date:      Thu Aug 04 10:45:52 2016 +0000

description:
Add a list of "module issues" based on an Email discussion between myself
and christos@

diffstat:

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

diffs (57 lines):

diff -r 74d916543359 -r 641dca727791 doc/TODO.modules
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/TODO.modules  Thu Aug 04 10:45:52 2016 +0000
@@ -0,0 +1,53 @@
+/* $NetBSD: TODO.modules,v 1.1 2016/08/04 10:45:52 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
+christos and pgoyette.
+
+1. Builtin drivers can't depend on modularized drivers (the modularized
+   drivers are attempted to load as builtins).
+
+       The assumption is that dependencies are loaded before those
+       modules which depend on them.  At load time, a module's
+       undefined global symbols are resolved;  if any symbols can't
+       be resolved, the load fails.  Similarly, if a module is
+       included in (built-into) the kernel, all of its symbols must
+       be resolvable by the linker, otherwise the link fails.
+
+       There are ways around this (such as, having the parent
+       module's initialization command recursively call the module
+       load code), but they're gross hacks.
+
+2. Currently, config(1) has no way to "no define" drivers
+
+3. It is not always obvious by their names which drivers/options
+   correspond to which modules.
+
+4. Right now critical drivers that would need to be pre-loaded (ffs,
+   exec_elf64) are still built-in so that we don't need to alter the boot
+   blocks to boot.
+
+       This was a conscious decision by core@ some years ago.  It is
+       not a requirement that ffs or exec_* be built-in.  The only
+       requirement is that the root file-system's module must be
+       available when the module subsystem is initialized, in order
+       to load other modules.  This can be accomplished by having the
+       boot loader "push" the module at boot time.  (It used to do
+       this in all cases; currently the "push" only occurs if the
+       booted filesystem is not ffs.)
+
+5. Not all parent bus drivers are capable of rescan, so some drivers
+   just have to be built-in.
+
+6. Many (most?) drivers are not yet modularized
+
+7. There's currently no provisions for autoconfig to figure out which
+   modules are needed, and thus to load the required modules.
+
+       In the "normal" built-in world, autoconfigure can only ask
+       existing drivers if they're willing to manage (ie, attach) a
+       device.  Removing the built-in drivers tends to limit the
+       availability of possible managers.  There's currently no
+       mechanism for identifying and loading drivers based on what
+       devices might be found.
+