From owner-freebsd-arch@FreeBSD.ORG Wed Jul 14 00:00:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8269016A4CE for ; Wed, 14 Jul 2004 00:00:57 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1294443D31 for ; Wed, 14 Jul 2004 00:00:57 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6E00d3S066475; Tue, 13 Jul 2004 20:00:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6E00cQP066470; Tue, 13 Jul 2004 20:00:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 13 Jul 2004 20:00:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20040713.174512.11239675.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c ) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 00:00:57 -0000 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: MOD_WEAKUNLOAD - Unload if you're not in use. I.e., unattached driver, unmounted file system, netgraph nodes that aren't instantiated, network protocol without any sockets, etc. Be harmlessly gone, but vetoed at a low cost. MOD_STRONGUNLOAD - Unload even though you're in use. Detach the driver, deadfs the file system, wither the geom, sever the sockets, etc. May cause disruption, but may also veto, depending on the subsystem, especially if the subsytem has no way to notify its consumers of impending doom. Can be vetoed, but try harder before vetoing. Some subsystems might always return EBUSY for this if there's really no way to express "undesirable departure" upwards. MOD_QUIESCE - Attempt MOD_WEAKUNLOAD, and if that fails, ask the module to start draining in some form. I'm a bit unclear on quite what's intended, but this seems to be less atomic notion than "unload, or don't" at various points on the spectrum. I.e., it kicks off a state transition in what is likely a slightly poorly defined state machine. Right now, the state machine is "Not loaded", "Loaded", and we use a lock to prevent intermediate states from colliding. MOD_SHUTDOWN - The system is shutting down, the module better do it too. Since there's no way to say "Um, no", most modules that don't know how to unload just ignore the event and in most cases it's harmless because the system state is toast shortly anyway. MOD_PANIC - Unload the module, regardless of the consequences. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research