[RFC] kldunload -f argument.

[Robert Watson]

On Fri, 9 Jul 2004, Brian Somers wrote:

> > I'm not sure I see any real-world application for this ?  Can you give an
> > example ?  Why would you load a module and not use it ?
> 
> I can't think of any non-development-environment reasons unless there's
> room for modules being loaded early to be able to make assumptions about
> their environment at ACTIVATE time (such as a root filesystem being
> available).

We actually have an example in the form of snd_driver, which forces all
the sound modules to load, with the intent that when you unload, the
attached ones are left running.  We also have a lot of functionality
compiled into GENERIC that many people don't use or use only infrequently
-- when that functionality is compiled into modules, we frequently
automatically load modules during a file system mount, netgraph pieces,
etc.  When they're no longer in use, they hang around.  In a world where
we consistently load modules on demand, and those modules remain idle
after use, it would be somewhat nice to be able to simply say "Ok, modules
no longer needed, please unload yourselves".

Note that other systems do this also -- Darwin loads a lot of hardware
device drivers early in the boot so that they can detect any devices
required for the boot.  They then unload the unreferenced ones and allow
the user space device pieces to reload them as needed for dynamic
hardware arrival.

> I guess if_tun.ko springs to mind.  I can reliably unload it if I
> quiesce it, kill all the ``Opened by PID N'' processes, then unload it. 

Note that "Opened by PID N" is actually unreliable if the process that
opened the tunnel does anything tricky, including fork and exit after
opening the tunnel.

> The MOD_ACTIVATE becomes more useful when a module ends up in a
> quiescent state for a long time - the user might want to change their
> mind instead of only being allowed to [try to] unload the now useless
> driver. 
> 
> Unless anyone's inspired to make any more pragmatic suggestions along
> these lines though, it's probably sensible to just skip the ACTIVATE
> idea :*) 

Well, I think it's important to think of all this as a state machine. 
During a clean and happy module unload, quiesce->unload may be a short
jump, but in a less happy unload, it may not be.  If we live in a world of
auto-loading modules on demand, we can't assume that the loading will
happen at a convenient time, so we need to assume it's possible for it to
happen while the module is already transitioning from the fully functional
state towards the unloaded state.  We either need to wait for it to
finish, then load the module again, or some other transition scheme that
results in the process loading the module not being told "Take a hike". 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research