cvs commit: src/sbin/kldunload kldunload.8 kldunload.c

Poul-Henning Kamp phk at phk.freebsd.dk
Tue Jul 13 12:55:37 PDT 2004


In message <40F43D36.2000407 at root.org>, Nate Lawson writes:
>Poul-Henning Kamp wrote:
>>   Give kldunload a -f(orce) argument.
>>   
>>   Add a MOD_QUIESCE event for modules.  This should return error (EBUSY)
>>   of the module is in use.
>>   
>>   MOD_UNLOAD should now only fail if it is impossible (as opposed to
>>   inconvenient) to unload the module.  Valid reasons are memory references
>>   into the module which cannot be tracked down and eliminated.
>>   
>>   When kldunloading, we abandon if MOD_UNLOAD fails, and if -force is
>>   not given, MOD_QUIESCE failing will also prevent the unload.
>
>Hmmm, a quick check of the archives shows that I missed your discussion 
>of this on Thursday/Friday when I was on vacation.  (Including the 
>extremely useful naming replies!)
>
>Have you kept up on the newbus discussions?  The tentative plan was to 
>add quiesce functionality to it as part of device_detach().  Doing it at 
>the module layer is a bit too low since there are events that can 
>trigger a detach but not an unload.  For instance, any driver compiled 
>into the kernel for an ejectable device will never be unloaded, but 
>certainly should quiesce/detach when the device is ejected.  Getting it 
>right in newbus automatically fixes the problem you're trying to solve 
>since a module unload always triggers a call to device_detach() but not 
>vice versa.
>
>I think duplicating this at multiple layers is not a good idea and the 
>module level is not the right layer to implement it.

Well, since one kld can contain multiple modules, and since the modules
get to veto an unload with MOD_UNLOAD, I don't really see how you can
come up with something that doesn't have a MOD_QUIESCE.

The fact that we have many modules which know nothing about newbus
also look like a pretty solid argument for needing it at the module
layer.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the cvs-src mailing list