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