Make MOD_QUIESCE a bit more useful..

John Baldwin jhb at
Mon Aug 11 15:44:56 UTC 2008

On Sunday 10 August 2008 06:53:33 pm M. Warner Losh wrote:
> In message: <200808091637.33820.jhb at>
>             John Baldwin <jhb at> writes:
> : So currently the MOD_QUIESCE event is posted to a module when unloading a 
> : so it can veto non-forced unloads.  However, the current implementation in 
> : the kernel linker is to run through all the modules in a file, posting 
> : MOD_QUIESCE followed by MOD_UNLOAD on each module serially.  Thus, if you 
> : have multiple modules in a single kld and one of the modules veto's an 
> : request via MOD_QUIESCE, you don't know as the module author if any of 
> : modules were unloaded via MOD_UNLOAD or not.  I think a better approach 
> : be to change the kernel linker to invoke MOD_QUIESCE on all modules in a 
> : single pass first.  If none of those fail (or it's a forced unload), then 
> : can do a second pass invoking MOD_UNLOAD on all the modules.
> That sounds great to me.  I'm a bit surprised it is implemented the
> way you say...

So was I.  What happens now is that the kernel linker does a for loop over all 
the modules calling 'module_unload()'.  module_unload() invokes both 
MOD_QUIESCE and MOD_UNLOAD back to back.

Hmm, so fixing this brings up one extra note: Do we need a new module event 
(say MOD_UNLOAD_ABORTED, MOD_AWAKEN, or MOD_DEQUIESCE) that would get invoked 
when a kldunload is veto'd by a MOD_QUIESCE event that would get posted to 
all the modules that had successfully QUIESCED so far?

John Baldwin

More information about the freebsd-arch mailing list