Home | History | Annotate | Line # | Download | only in doc
TODO.modules revision 1.1
      1 /* $NetBSD: TODO.modules,v 1.1 2016/08/04 10:45:52 pgoyette Exp $ */
      2 
      3 Some notes on the limitations of our current (as of 7.99.35) module
      4 subsystem.  This list was triggered by an Email exchange between
      5 christos and pgoyette.
      6 
      7 1. Builtin drivers can't depend on modularized drivers (the modularized
      8    drivers are attempted to load as builtins).
      9 
     10 	The assumption is that dependencies are loaded before those
     11 	modules which depend on them.  At load time, a module's
     12 	undefined global symbols are resolved;  if any symbols can't
     13 	be resolved, the load fails.  Similarly, if a module is
     14 	included in (built-into) the kernel, all of its symbols must
     15 	be resolvable by the linker, otherwise the link fails.
     16 
     17 	There are ways around this (such as, having the parent
     18 	module's initialization command recursively call the module
     19 	load code), but they're gross hacks.
     20 
     21 2. Currently, config(1) has no way to "no define" drivers
     22 
     23 3. It is not always obvious by their names which drivers/options
     24    correspond to which modules.
     25 
     26 4. Right now critical drivers that would need to be pre-loaded (ffs,
     27    exec_elf64) are still built-in so that we don't need to alter the boot
     28    blocks to boot.
     29 
     30 	This was a conscious decision by core@ some years ago.  It is
     31 	not a requirement that ffs or exec_* be built-in.  The only
     32 	requirement is that the root file-system's module must be
     33 	available when the module subsystem is initialized, in order
     34 	to load other modules.  This can be accomplished by having the
     35 	boot loader "push" the module at boot time.  (It used to do
     36 	this in all cases; currently the "push" only occurs if the
     37 	booted filesystem is not ffs.)
     38 
     39 5. Not all parent bus drivers are capable of rescan, so some drivers
     40    just have to be built-in.
     41 
     42 6. Many (most?) drivers are not yet modularized
     43 
     44 7. There's currently no provisions for autoconfig to figure out which
     45    modules are needed, and thus to load the required modules.
     46 
     47 	In the "normal" built-in world, autoconfigure can only ask
     48 	existing drivers if they're willing to manage (ie, attach) a
     49 	device.  Removing the built-in drivers tends to limit the
     50 	availability of possible managers.  There's currently no
     51 	mechanism for identifying and loading drivers based on what
     52 	devices might be found.
     53 
     54