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 | -------------------------------------------------------------------------