Modules loading modules?

[Paul Goyette <paul%whooppee.com@localhost>]

Consider the following scenario:

We have a modular device driver, let's call it xxxmod.  The driver's
xxx_modcmd(MODULE_CMD_INIT, ...) routine handles all of its initialization,
including interaction with autoconf(9).  It therefore might attempt to use
an optional module (e.g., zzzverbose) to print some device attachment
messages.

(Another possible scenario would be to have one modular driver xxxmod
that calls config_found_xxx() which in turn requires another modular
driver yyymod.)

We have no problem if the zzzverbose module is already auto-loaded. But
if the module is not present, or if it has already been auto- unloaded,
the current code will call module_autoload() to attempt to (re)load it.
Since this call happens in xxx_modcmd(), we end calling mutex_enter()
while the mutex is still owned.

There is currently a "requires" mechanism that allows recursion within
the module loading process.  But it doesn't quite solve the problem, for
at least three reasons.  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.
(A key benefit of having the xxx_verbose modules is that their large text
tables can be unloaded.)

A third reason that tends to make this option unuseable is the need to
identify ahead of time all of the possible optional modules and maintain
the dependency list.  Adding a new driver would thus require updating the
dependency list in the parent device's driver.

Any suggestions on how to resolve this conundrum?  Without a solution,
the zzz_verbose modules and modularized drivers that might use the 
zzz_verbose modules cannot co-exist, and we won't be able to have modular
drivers for devices whose children are served by other modular drivers.



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