On Mon, 26 Jul 2010, der Mouse wrote:
We have a modular device driver, let's call it xxxmod. [...] It []
might attempt to use an optional module (e.g., zzzverbose) to print
some device attachment messages.
First, a required module cannot be optional. If the desired module
is not present, or if it is present but its own
xxx_modcmd(MODULE_CMD_INIT, ...) fails, the failure is propagated
back to the original "outer" call to module_load() which will also
fail.
The second reason why this is not suitable is that the "outer" load
will add a reference to the module, preventing it from being
auto-unloaded.
Surely the right answer here is to provide a way to say "refer to this
module, but it's ok for its load to fail, and it's ok for it to get
auto-unloaded", including passing up whatever information is necessary
for the calling module to do something useful in failure cases?
I actually considered adding a set of "desired" modules as well as the
current "required" modules. That would certainly take care of the
immediate problem with the xxx_verbose modules.
But it doesn't address the need to have one module/driver loading
another one for a child device, and it would be a maintenance nightmare
to require updating the dependency-list every time a new child driver
gets created.
It really seems to me that the module system is there to help us, not
to shackle us, and that if it has properties which are leading to
problems, one of the options we should at the very least be considering
is changing those properties.
Yes, the current restriction appears to be burdensome. I'm just trying
to get some consensus on that - so far I've seen only one negative
opinion (from pooka@ IIRC). If we can agree that it's desirable for one
module's xxx_modcmd() to load another module, then we can move to step 2
and figure out how to make it happen without breaking anything.
If we don't get consensus, then I'll most likely need to revert the
xxx_verbose modules.
-------------------------------------------------------------------------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-------------------------------------------------------------------------
