On Sat, 15 Jan 2022, matthew green wrote:
it seems to me that if some driver depends upon altq, then
altq should simply always refuse to unload if a driver is
loaded that depends upon it. this should be an explicit
dependency, and probably implicit via symbols.
if, say there's a fully modular system with two NICs, and
only one of them supports altq. only one of the NIC drivers
will declare a dep on altq, blocking the unload of altq
while the driver remains loaded.
if this isn't already the case, can we arrange it to be?
I see the problem a little differently. The driver doesn't
actually _depend_ on altq, but it does different (perhaps
additional) things based on whether altq is present or not.
Currently the present-or-not decision is done at compile-
time based on ``options ALTQ'', but it should be possible to
make the present-or-not decision at run-time.
The sample pseudo-code in my original post could use the
existing module_hooks, so it becomes more like:
...
MODULE_HOOK_CALL(altq-part-A-hook);
{common code}
MODULE_HOOK_CALL(altq-part-B-hook);
...
but with an additional mechanism to prevent a load/unload
in between the two hook calls.
I'm going to dig in a little bit deeper into the ALTQ code;
perhaps in some cases the part-A/part-B code can be coalesed
into a single hook and the problem goes away. That would
address the immediate concern for ALTQ but I suspect that it
will resurface later on for some other option/module.
+--------------------+--------------------------+----------------------+
| 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 |
+--------------------+--------------------------+----------------------+
