re: Some guidance/suggestion please

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

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 | paul%whooppee.com@localhost    |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost  |
| & Network Engineer |                          | pgoyette99%gmail.com@localhost |
+--------------------+--------------------------+----------------------+