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

[Nate Lawson]

Poul-Henning Kamp wrote:
> In message <40F43D36.2000407 at root.org>, Nate Lawson writes:
> 
>>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.

There are two parts, the internal structure and interfaces.  The 
internal structure should obviously be one or more calls to 
device_detach().  The external interface does not exist yet and you're 
welcome to contribute.  There is at least a usermode component ("eject 
ed0") and a kernel mode component ("this device_t will soon be gone").
Of course, there will be more than this.

To address your specific issue, there doesn't have to be MOD_QUIESCE. 
The normal MOD_UNLOAD request will trigger (multiple calls to) 
device_detach via a TBD kernel interface.  This detach needs to be 
multiple pass (notify, gone).

> 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.

Let's focus on how to improve things, not the fact that things aren't 
perfect right now.

-- 
-Nate