TODO.modules revision 1.7
1 /* $NetBSD: TODO.modules,v 1.7 2016/09/27 22:54:57 christos 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 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 28 2. Currently, config(1) has no way to "no define" drivers 29 XXX: I don't think this is true anymore. I think we can 30 undefine drivers now, see MODULAR in amd64, which does 31 no ath* and no select sppp* 32 33 3. It is not always obvious by their names which drivers/options 34 correspond to which modules. 35 36 4. Right now critical drivers that would need to be pre-loaded (ffs, 37 exec_elf64) are still built-in so that we don't need to alter the boot 38 blocks to boot. 39 40 This was a conscious decision by core@ some years ago. It is 41 not a requirement that ffs or exec_* be built-in. The only 42 requirement is that the root file-system's module must be 43 available when the module subsystem is initialized, in order 44 to load other modules. This can be accomplished by having the 45 boot loader "push" the module at boot time. (It used to do 46 this in all cases; currently the "push" only occurs if the 47 booted filesystem is not ffs.) 48 49 5. Not all parent bus drivers are capable of rescan, so some drivers 50 just have to be built-in. 51 52 6. Many (most?) drivers are not yet modularized 53 54 7. There's currently no provisions for autoconfig to figure out which 55 modules are needed, and thus to load the required modules. 56 57 In the "normal" built-in world, autoconfigure can only ask 58 existing drivers if they're willing to manage (ie, attach) a 59 device. Removing the built-in drivers tends to limit the 60 availability of possible managers. There's currently no 61 mechanism for identifying and loading drivers based on what 62 devices might be found. 63 64 8. Even for existing modules, there are "surprise" dependencies with 65 code that has not yet been modularized. 66 67 For example, even though the bpf code has been modularized, 68 there is some shared code in bpf_filter.c which is needed by 69 both ipfilter and ppp. ipf is already modularized, but ppp 70 is not. Thus, even though bpf_filter is modular, it MUST be 71 included as a built-in module if you also have ppp in your 72 configuration. 73 74 Another example is sysmon_taskq module. It is required by 75 other parts of the sysmon subsystem, including the 76 "sysmon_power" module. Unfortunately, even though the 77 sysmon_power code is modularized, it is referenced by the 78 acpi code which has not been modularized. Therefore, if your 79 configuration has acpi, then you must include the "sysmon_power" 80 module built-in the kernel. And therefore your also need to 81 have "sysmon_taskq" and "sysmon" built-in since "sysmon_power" 82 rerefences them. 83 84 9. As a corollary to #8 above, having dependencies on modules from code 85 which has not been modularized makes it extremely difficult to test 86 the module code adequately. Testing of module code should include 87 both testing-as-a-built-in module and testing-as-a-loaded-module, and 88 all dependencies need to be identified. 89 90 10. The current /stand/$ARCH/$VERSION/modules/ hierarchy won't scale as 91 we get more and more modules. There are hundreds of potential device 92 driver modules. 93 94 11. There currently isn't any good way to handle attachment-specific 95 modules. The build infrastructure (ie, sys/modules/Makefile) doesn't 96 readily lend itself to bus-specific modules irrespective of $ARCH, 97 and maintaining distrib/sets/lists/modules/* is awkward at best. 98 99 Furthermore, devices such as ld(4), which can attach to a large set 100 of parent devices, need to be modified. The parent devices need to 101 provide a common attribute (for example, ld_bud), and the ld driver 102 should attach to that attribute rather than to each parent. But 103 currently, config(1) doesn't handle this - it doesn't allow an 104 attribute to be used as the device tree's pseudo-root. The current 105 directory structure where driver foo is split between ic/foo.c 106 and bus1/foo_bus1.c ... busn/foo_busn.c is annoying. It would be 107 better to switch to the FreeBSD model which puts all the driver 108 files in one directory. 109 110 12. Item #11 gets even murkier when a particular parent can provide more 111 than one attribute. 112
Indexes created Thu Sep 25 16:09:42 GMT 2025