Date: Tue, 13 Jul 2004 13:42:40 -0700 From: Nate Lawson <nate@root.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c Message-ID: <40F44940.4020406@root.org> In-Reply-To: <23944.1089748527@critter.freebsd.dk> References: <23944.1089748527@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <40F43D36.2000407@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40F44940.4020406>