TODO.modules revision 1.2
1 /* $NetBSD: TODO.modules,v 1.2 2016/08/04 22:12:31 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 8. 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 74 9. 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
Indexes created Thu Sep 25 16:09:42 GMT 2025