TODO.modules revision 1.2 
1/* $NetBSD: TODO.modules,v 1.2 2016/08/04 22:12:31 pgoyette Exp $ */
2
3Some notes on the limitations of our current (as of 7.99.35) module
4subsystem.  This list was triggered by an Email exchange between
5christos and pgoyette.
6
71. 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
212. Currently, config(1) has no way to "no define" drivers
22
233. It is not always obvious by their names which drivers/options
24   correspond to which modules.
25
264. 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
395. Not all parent bus drivers are capable of rescan, so some drivers
40   just have to be built-in.
41
426. Many (most?) drivers are not yet modularized
43
447. 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
548. Even for existing modules, there are "surprise" dependencies with
55   code that has not yet been modularized.
56
57	For example, even though the bpf code has been modularized,
58	there is some shared code in bpf_filter.c which is needed by
59	both ipfilter and ppp.  ipf is already modularized, but ppp
60	is not.  Thus, even though bpf_filter is modular, it MUST be
61	included as a built-in module if you also have ppp in your
62	configuration.
63
64	Another example is sysmon_taskq module.  It is required by
65	other parts of the sysmon subsystem, including the
66	"sysmon_power" module.  Unfortunately, even though the
67	sysmon_power code is modularized, it is referenced by the
68	acpi code which has not been modularized.  Therefore, if your
69	configuration has acpi, then you must include the "sysmon_power"
70	module built-in the kernel.  And therefore your also need to
71	have "sysmon_taskq" and "sysmon" built-in since "sysmon_power"
72	rerefences them.
73
749. As a corollary to #8 above, having dependencies on modules from code
75   which has not been modularized makes it extremely difficult to test
76   the module code adequately.  Testing of module code should include
77   both testing-as-a-built-in module and testing-as-a-loaded-module, and
78   all dependencies need to be identified.
79