TODO.modules revision 1.4.2.4
1 1.4.2.4 pgoyette /* $NetBSD: TODO.modules,v 1.4.2.4 2017/01/07 08:53:45 pgoyette Exp $ */ 2 1.4.2.2 pgoyette 3 1.4.2.2 pgoyette Some notes on the limitations of our current (as of 7.99.35) module 4 1.4.2.2 pgoyette subsystem. This list was triggered by an Email exchange between 5 1.4.2.2 pgoyette christos and pgoyette. 6 1.4.2.2 pgoyette 7 1.4.2.3 pgoyette 1. Builtin drivers can't depend on modularized drivers (the modularized 8 1.4.2.3 pgoyette drivers are attempted to load as builtins). 9 1.4.2.2 pgoyette 10 1.4.2.2 pgoyette The assumption is that dependencies are loaded before those 11 1.4.2.2 pgoyette modules which depend on them. At load time, a module's 12 1.4.2.2 pgoyette undefined global symbols are resolved; if any symbols can't 13 1.4.2.2 pgoyette be resolved, the load fails. Similarly, if a module is 14 1.4.2.2 pgoyette included in (built-into) the kernel, all of its symbols must 15 1.4.2.2 pgoyette be resolvable by the linker, otherwise the link fails. 16 1.4.2.2 pgoyette 17 1.4.2.2 pgoyette There are ways around this (such as, having the parent 18 1.4.2.2 pgoyette module's initialization command recursively call the module 19 1.4.2.2 pgoyette load code), but they're gross hacks. 20 1.4.2.2 pgoyette 21 1.4.2.3 pgoyette 2. Currently, config(1) has no way to "no define" drivers 22 1.4.2.3 pgoyette XXX: I don't think this is true anymore. I think we can 23 1.4.2.3 pgoyette undefine drivers now, see MODULAR in amd64, which does 24 1.4.2.3 pgoyette no ath* and no select sppp* 25 1.4.2.3 pgoyette 26 1.4.2.3 pgoyette 3. It is not always obvious by their names which drivers/options 27 1.4.2.3 pgoyette correspond to which modules. 28 1.4.2.3 pgoyette 29 1.4.2.3 pgoyette 4. Right now critical drivers that would need to be pre-loaded (ffs, 30 1.4.2.3 pgoyette exec_elf64) are still built-in so that we don't need to alter the boot 31 1.4.2.3 pgoyette blocks to boot. 32 1.4.2.2 pgoyette 33 1.4.2.2 pgoyette This was a conscious decision by core@ some years ago. It is 34 1.4.2.2 pgoyette not a requirement that ffs or exec_* be built-in. The only 35 1.4.2.2 pgoyette requirement is that the root file-system's module must be 36 1.4.2.2 pgoyette available when the module subsystem is initialized, in order 37 1.4.2.2 pgoyette to load other modules. This can be accomplished by having the 38 1.4.2.2 pgoyette boot loader "push" the module at boot time. (It used to do 39 1.4.2.2 pgoyette this in all cases; currently the "push" only occurs if the 40 1.4.2.2 pgoyette booted filesystem is not ffs.) 41 1.4.2.2 pgoyette 42 1.4.2.3 pgoyette 5. Not all parent bus drivers are capable of rescan, so some drivers 43 1.4.2.3 pgoyette just have to be built-in. 44 1.4.2.2 pgoyette 45 1.4.2.3 pgoyette 6. Many (most?) drivers are not yet modularized 46 1.4.2.2 pgoyette 47 1.4.2.3 pgoyette 7. There's currently no provisions for autoconfig to figure out which 48 1.4.2.3 pgoyette modules are needed, and thus to load the required modules. 49 1.4.2.2 pgoyette 50 1.4.2.2 pgoyette In the "normal" built-in world, autoconfigure can only ask 51 1.4.2.2 pgoyette existing drivers if they're willing to manage (ie, attach) a 52 1.4.2.2 pgoyette device. Removing the built-in drivers tends to limit the 53 1.4.2.2 pgoyette availability of possible managers. There's currently no 54 1.4.2.2 pgoyette mechanism for identifying and loading drivers based on what 55 1.4.2.2 pgoyette devices might be found. 56 1.4.2.2 pgoyette 57 1.4.2.3 pgoyette 8. Even for existing modules, there are "surprise" dependencies with 58 1.4.2.3 pgoyette code that has not yet been modularized. 59 1.4.2.2 pgoyette 60 1.4.2.2 pgoyette For example, even though the bpf code has been modularized, 61 1.4.2.2 pgoyette there is some shared code in bpf_filter.c which is needed by 62 1.4.2.2 pgoyette both ipfilter and ppp. ipf is already modularized, but ppp 63 1.4.2.2 pgoyette is not. Thus, even though bpf_filter is modular, it MUST be 64 1.4.2.2 pgoyette included as a built-in module if you also have ppp in your 65 1.4.2.2 pgoyette configuration. 66 1.4.2.2 pgoyette 67 1.4.2.2 pgoyette Another example is sysmon_taskq module. It is required by 68 1.4.2.2 pgoyette other parts of the sysmon subsystem, including the 69 1.4.2.2 pgoyette "sysmon_power" module. Unfortunately, even though the 70 1.4.2.2 pgoyette sysmon_power code is modularized, it is referenced by the 71 1.4.2.2 pgoyette acpi code which has not been modularized. Therefore, if your 72 1.4.2.2 pgoyette configuration has acpi, then you must include the "sysmon_power" 73 1.4.2.2 pgoyette module built-in the kernel. And therefore your also need to 74 1.4.2.2 pgoyette have "sysmon_taskq" and "sysmon" built-in since "sysmon_power" 75 1.4.2.2 pgoyette rerefences them. 76 1.4.2.2 pgoyette 77 1.4.2.3 pgoyette 9. As a corollary to #8 above, having dependencies on modules from code 78 1.4.2.3 pgoyette which has not been modularized makes it extremely difficult to test 79 1.4.2.3 pgoyette the module code adequately. Testing of module code should include 80 1.4.2.3 pgoyette both testing-as-a-built-in module and testing-as-a-loaded-module, and 81 1.4.2.3 pgoyette all dependencies need to be identified. 82 1.4.2.3 pgoyette 83 1.4.2.3 pgoyette 10. The current /stand/$ARCH/$VERSION/modules/ hierarchy won't scale as 84 1.4.2.3 pgoyette we get more and more modules. There are hundreds of potential device 85 1.4.2.3 pgoyette driver modules. 86 1.4.2.3 pgoyette 87 1.4.2.3 pgoyette 11. There currently isn't any good way to handle attachment-specific 88 1.4.2.3 pgoyette modules. The build infrastructure (ie, sys/modules/Makefile) doesn't 89 1.4.2.3 pgoyette readily lend itself to bus-specific modules irrespective of $ARCH, 90 1.4.2.3 pgoyette and maintaining distrib/sets/lists/modules/* is awkward at best. 91 1.4.2.3 pgoyette 92 1.4.2.3 pgoyette Furthermore, devices such as ld(4), which can attach to a large set 93 1.4.2.3 pgoyette of parent devices, need to be modified. The parent devices need to 94 1.4.2.3 pgoyette provide a common attribute (for example, ld_bus), and the ld driver 95 1.4.2.3 pgoyette should attach to that attribute rather than to each parent. But 96 1.4.2.3 pgoyette currently, config(1) doesn't handle this - it doesn't allow an 97 1.4.2.3 pgoyette attribute to be used as the device tree's pseudo-root. The current 98 1.4.2.3 pgoyette directory structure where driver foo is split between ic/foo.c 99 1.4.2.3 pgoyette and bus1/foo_bus1.c ... busn/foo_busn.c is annoying. It would be 100 1.4.2.3 pgoyette better to switch to the FreeBSD model which puts all the driver 101 1.4.2.3 pgoyette files in one directory. 102 1.4.2.2 pgoyette 103 1.4.2.3 pgoyette 12. Item #11 gets even murkier when a particular parent can provide more 104 1.4.2.3 pgoyette than one attribute. 105 1.4.2.4 pgoyette 106 1.4.2.4 pgoyette 13. It seems that we might want some additional sets-lists "attributes" 107 1.4.2.4 pgoyette to control contents of distributions. As an example, many of our 108 1.4.2.4 pgoyette architectures have PCI bus capabilities, but not all. It is rather 109 1.4.2.4 pgoyette painful to need to maintain individual architectures' modules/md_* 110 1.4.2.4 pgoyette sets lists, especially when we already have to conditionalize the 111 1.4.2.4 pgoyette build of the modules based on architecture. If we had a single 112 1.4.2.4 pgoyette "attribute" for PCI-bus-capable, the same attribute could be used to 113 1.4.2.4 pgoyette select which modules to build and which modules from modules/mi to 114 1.4.2.4 pgoyette include in the release. (This is not limited to PCI; recently we 115 1.4.2.4 pgoyette encounter similar issues with spkr aka spkr_synth module.) 116
Indexes created Thu Oct 23 22:10:10 GMT 2025