Module Name: src
Committed By: pgoyette
Date: Thu Aug 4 10:45:52 UTC 2016
Added Files:
src/doc: TODO.modules
Log Message:
Add a list of "module issues" based on an Email discussion between myself
and christos@
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/doc/TODO.modules
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Added files:
Index: src/doc/TODO.modules
diff -u /dev/null src/doc/TODO.modules:1.1
--- /dev/null Thu Aug 4 10:45:52 2016
+++ src/doc/TODO.modules Thu Aug 4 10:45:52 2016
@@ -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.
+
