diff options
| author | pgoyette <pgoyette@NetBSD.org> | 2016-08-04 10:45:52 +0000 |
|---|---|---|
| committer | pgoyette <pgoyette@NetBSD.org> | 2016-08-04 10:45:52 +0000 |
| commit | 606c92a6b551bd7442f7a4ea428d05bf4e45b13d (patch) | |
| tree | 54cd3ffed77ca7c94b05beda7b78e15850a15f64 /doc/TODO.modules | |
| parent | adf18317f7916bf935a0bb500fcc8b81b721c4c7 (diff) | |
Add a list of "module issues" based on an Email discussion between myself
and christos@
Diffstat (limited to 'doc/TODO.modules')
| -rw-r--r-- | doc/TODO.modules | 53 |
1 files changed, 53 insertions, 0 deletions
diff --git a/doc/TODO.modules b/doc/TODO.modules new file mode 100644 index 00000000000..91827472612 --- /dev/null +++ b/doc/TODO.modules @@ -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. + |
