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
m...@eterna.com.au (matthew green) writes:
>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
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
On Jan 14, 9:11, Paul Goyette wrote:
}
} 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,
On Fri, Jan 14, 2022 at 09:11:08AM -0800, Paul Goyette wrote:
> #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
