Date: Tue, 13 Jul 2004 14:24:09 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c Message-ID: <20040713.142409.35661941.imp@bsdimp.com> In-Reply-To: <40F43D36.2000407@root.org> References: <20040713193703.ECB0016A53F@hub.freebsd.org> <40F43D36.2000407@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <40F43D36.2000407@root.org>
Nate Lawson <nate@root.org> 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.
Actually, the talk was that newbus would grow knowledge of these
things as well. MOD_QUIESCE would translate into something sensible
at the newbus layer that would also be used for other things that are
related. The glue layer hasn't been translated because phk didn't
want to hear about it when he soliticed requests and didn't want to
talk about the implications for newbus.
Newbus will need to understand this new message, but it has nothing to
connect it to at the moment.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040713.142409.35661941.imp>