Date: Wed, 14 Jul 2004 09:54:26 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c ) Message-ID: <36295.1089791666@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 13 Jul 2004 20:00:37 EDT." <Pine.NEB.3.96L.1040713195126.63836A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1040713195126.63836A-100000@fledge.watson.org>, Robe rt Watson writes: > >On Tue, 13 Jul 2004, M. Warner Losh wrote: > >> The nasty case I've come up with is what happens when the module is idle >> (not busy), but becomes busy (not idle) after the MOD_QUIESCE call? >> Right now newbus modules that receive a MOD_UNLOAD call attempt to >> detach all instances of devices contained in that module. If I have a >> way to poll the driver to see if it is busy (which is relatively easy to >> implement), then if it becomes busy after the MOD_QUIESCE call, I get a >> MOD_UNLOAD which would force instances to detach. > >So, it sounds like a couple of concepts are floating around: I considered most of what you suggest here myself but concluded that since we had been able to get by with only -force in mount for so long, we really only needed two levels: MOD_QUIESCE "stop and prepare for unload if not in use" MOD_UNLOAD "unload unless there are memory references into the module which cannot be invalidated" I did make the kldunloadf() take a flag argument so if people want higher granularity more can be added, but remember that would come at a cost of more code in all modules. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36295.1089791666>