1/* $NetBSD: TODO.modules,v 1.5 2016/08/06 00:30:57 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 often gross hacks. 20 21 Another alternative (which is used by ppp) is to provide a 22 "registration" mechanism for the "child" modules, and then when 23 the need for a specific child module is encountered, use 24 module_autoload() to load the child module. Of course, this 25 requires that the parent module know about all potentially 26 loadable children. 27 282. Currently, config(1) has no way to "no define" drivers 29 303. It is not always obvious by their names which drivers/options 31 correspond to which modules. 32 334. Right now critical drivers that would need to be pre-loaded (ffs, 34 exec_elf64) are still built-in so that we don't need to alter the boot 35 blocks to boot. 36 37 This was a conscious decision by core@ some years ago. It is 38 not a requirement that ffs or exec_* be built-in. The only 39 requirement is that the root file-system's module must be 40 available when the module subsystem is initialized, in order 41 to load other modules. This can be accomplished by having the 42 boot loader "push" the module at boot time. (It used to do 43 this in all cases; currently the "push" only occurs if the 44 booted filesystem is not ffs.) 45 465. Not all parent bus drivers are capable of rescan, so some drivers 47 just have to be built-in. 48 496. Many (most?) drivers are not yet modularized 50 517. There's currently no provisions for autoconfig to figure out which 52 modules are needed, and thus to load the required modules. 53 54 In the "normal" built-in world, autoconfigure can only ask 55 existing drivers if they're willing to manage (ie, attach) a 56 device. Removing the built-in drivers tends to limit the 57 availability of possible managers. There's currently no 58 mechanism for identifying and loading drivers based on what 59 devices might be found. 60 618. Even for existing modules, there are "surprise" dependencies with 62 code that has not yet been modularized. 63 64 For example, even though the bpf code has been modularized, 65 there is some shared code in bpf_filter.c which is needed by 66 both ipfilter and ppp. ipf is already modularized, but ppp 67 is not. Thus, even though bpf_filter is modular, it MUST be 68 included as a built-in module if you also have ppp in your 69 configuration. 70 71 Another example is sysmon_taskq module. It is required by 72 other parts of the sysmon subsystem, including the 73 "sysmon_power" module. Unfortunately, even though the 74 sysmon_power code is modularized, it is referenced by the 75 acpi code which has not been modularized. Therefore, if your 76 configuration has acpi, then you must include the "sysmon_power" 77 module built-in the kernel. And therefore your also need to 78 have "sysmon_taskq" and "sysmon" built-in since "sysmon_power" 79 rerefences them. 80 819. As a corollary to #8 above, having dependencies on modules from code 82 which has not been modularized makes it extremely difficult to test 83 the module code adequately. Testing of module code should include 84 both testing-as-a-built-in module and testing-as-a-loaded-module, and 85 all dependencies need to be identified. 86 87