I'm looking into more modularization of the kernel, and my next
"target" is the ALTQ stuff. Right now, there are several network
device drivers that are built as loadable modules, yet they still
depend on conditional compilation. In particular, there seems to
be some number of code fragments similar to
...
#ifdef ALTQ
altq-code-part-A
#endif
(common code)
#ifdef ALTQ
altq-code-part-B
#endif
...
The existing module_hook mechanism doesn't help us here. We can
make the two pieces of altq code into module hooks, but that
doesn't handle the case where the module gets loaded or unloaded
between the two parts of the altq code.
We have the module_hold()/module_rele() mechanism but they're not
really appropriate here. Both routines require us to already have
access to the module's data in its struct module.
So, I'm pretty sure we need a new mechanism, one that prevents a
module from being unloaded during critical sequences. This new
mechanism needs to also prevent a module from being newly loaded
(or at least, from installing any new hooks); otherwise we could
potentially execute the part-B code without have run any part-A
code on which part-B might depend. Therefore the mechanism cannot
live within the module itself.
FWIW, I vaguely remember having one or two instances of this issue
during my work on the compat modules (some years ago). I think I
addressed these by making explicit checks on the hook->hooked
member, but that's not really correct. (Unfortunately I can't
remember any details on this...)
Anyone got any suggestions?
+--------------------+--------------------------+----------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
+--------------------+--------------------------+----------------------+
