From owner-freebsd-arch@FreeBSD.ORG Wed Jul 14 07:51:29 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 0819F16A4CE; Wed, 14 Jul 2004 07:51:29 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5759043D3F; Wed, 14 Jul 2004 07:51:28 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6E7ow2B036245; Wed, 14 Jul 2004 09:50:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 13 Jul 2004 17:45:12 MDT." <20040713.174512.11239675.imp@bsdimp.com> Date: Wed, 14 Jul 2004 09:50:58 +0200 Message-ID: <36244.1089791458@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: rwatson@freebsd.org 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 07:51:29 -0000 In message <20040713.174512.11239675.imp@bsdimp.com>, "M. Warner Losh" writes: >I've not seen other documentation that explains the event in more >detail. Nor do I see comments in the code explaining it any better. >>From reading the code and the docs, MOD_QUIESCE is just a 'are you >idle?' question. More like "If you are idle, prepare to be unloaded, otherwise yell". >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? That is for the module to handle: if it returns zero to MOD_QUIESCE it knows it will be unloaded and shouldn't accept any new business. Finegrained guidance for what a module should do in MOD_QUISCE: Network driver: If any instance is IF_UP, return EBUSY. Otherwise detach all instances and do not attach to any new instances offered. Device driver: If any instance is opened, return EBUSY. Otherwise destroy_dev all instances and do not attach to any new instances offered. GEOM module: If any provider has non-zero access counts, return EBUSY. Otherwise orphan all providers, destroy or wither all geoms + consumers and do not taste/configure new instances. MOD_UNLOAD on the other hand means: All kinds of module: Clean all instances even if they are in use. Return error only if something cannot be cleaned up, for instance memory references into the module we cannot reclaim. The fact that an in-use instance is cleaned makes other code in the kernel with insufficient error-checks fail is _not_ a reason to return error, the other code should be fixed instead. And as I said earlier: if you give -f to kldunload the MOD_QUISCE error return is ignored and MOD_UNLOAD issued anyway. -- 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.