87 lines
3.8 KiB
Plaintext
87 lines
3.8 KiB
Plaintext
/* $NetBSD: TODO.modules,v 1.5 2016/08/06 00:30:57 pgoyette Exp $ */
|
|
|
|
Some notes on the limitations of our current (as of 7.99.35) module
|
|
subsystem. This list was triggered by an Email exchange between
|
|
christos and pgoyette.
|
|
|
|
1. Builtin drivers can't depend on modularized drivers (the modularized
|
|
drivers are attempted to load as builtins).
|
|
|
|
The assumption is that dependencies are loaded before those
|
|
modules which depend on them. At load time, a module's
|
|
undefined global symbols are resolved; if any symbols can't
|
|
be resolved, the load fails. Similarly, if a module is
|
|
included in (built-into) the kernel, all of its symbols must
|
|
be resolvable by the linker, otherwise the link fails.
|
|
|
|
There are ways around this (such as, having the parent
|
|
module's initialization command recursively call the module
|
|
load code), but they're often gross hacks.
|
|
|
|
Another alternative (which is used by ppp) is to provide a
|
|
"registration" mechanism for the "child" modules, and then when
|
|
the need for a specific child module is encountered, use
|
|
module_autoload() to load the child module. Of course, this
|
|
requires that the parent module know about all potentially
|
|
loadable children.
|
|
|
|
2. Currently, config(1) has no way to "no define" drivers
|
|
|
|
3. It is not always obvious by their names which drivers/options
|
|
correspond to which modules.
|
|
|
|
4. Right now critical drivers that would need to be pre-loaded (ffs,
|
|
exec_elf64) are still built-in so that we don't need to alter the boot
|
|
blocks to boot.
|
|
|
|
This was a conscious decision by core@ some years ago. It is
|
|
not a requirement that ffs or exec_* be built-in. The only
|
|
requirement is that the root file-system's module must be
|
|
available when the module subsystem is initialized, in order
|
|
to load other modules. This can be accomplished by having the
|
|
boot loader "push" the module at boot time. (It used to do
|
|
this in all cases; currently the "push" only occurs if the
|
|
booted filesystem is not ffs.)
|
|
|
|
5. Not all parent bus drivers are capable of rescan, so some drivers
|
|
just have to be built-in.
|
|
|
|
6. Many (most?) drivers are not yet modularized
|
|
|
|
7. There's currently no provisions for autoconfig to figure out which
|
|
modules are needed, and thus to load the required modules.
|
|
|
|
In the "normal" built-in world, autoconfigure can only ask
|
|
existing drivers if they're willing to manage (ie, attach) a
|
|
device. Removing the built-in drivers tends to limit the
|
|
availability of possible managers. There's currently no
|
|
mechanism for identifying and loading drivers based on what
|
|
devices might be found.
|
|
|
|
8. Even for existing modules, there are "surprise" dependencies with
|
|
code that has not yet been modularized.
|
|
|
|
For example, even though the bpf code has been modularized,
|
|
there is some shared code in bpf_filter.c which is needed by
|
|
both ipfilter and ppp. ipf is already modularized, but ppp
|
|
is not. Thus, even though bpf_filter is modular, it MUST be
|
|
included as a built-in module if you also have ppp in your
|
|
configuration.
|
|
|
|
Another example is sysmon_taskq module. It is required by
|
|
other parts of the sysmon subsystem, including the
|
|
"sysmon_power" module. Unfortunately, even though the
|
|
sysmon_power code is modularized, it is referenced by the
|
|
acpi code which has not been modularized. Therefore, if your
|
|
configuration has acpi, then you must include the "sysmon_power"
|
|
module built-in the kernel. And therefore your also need to
|
|
have "sysmon_taskq" and "sysmon" built-in since "sysmon_power"
|
|
rerefences them.
|
|
|
|
9. As a corollary to #8 above, having dependencies on modules from code
|
|
which has not been modularized makes it extremely difficult to test
|
|
the module code adequately. Testing of module code should include
|
|
both testing-as-a-built-in module and testing-as-a-loaded-module, and
|
|
all dependencies need to be identified.
|
|
|