Date: Tue, 13 Jul 2004 13:54:38 -0600 From: Scott Long <scottl@freebsd.org> To: Nate Lawson <nate@root.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c Message-ID: <40F43DFE.3000402@freebsd.org> 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
Nate Lawson wrote: > 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. > It typically won't be duplicated. This particular work is good for things like GEOM modules that don't fit into newbus. If at some point in the future newbus becomes aware of pseudo-drivers (drivers not attached by a hardware bus) then this should indeed be revisited. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40F43DFE.3000402>