From owner-freebsd-arch@FreeBSD.ORG  Sun Aug 10 22:55:37 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CDFC0106566B;
	Sun, 10 Aug 2008 22:55:37 +0000 (UTC) (envelope-from imp@bsdimp.com)
Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85])
	by mx1.freebsd.org (Postfix) with ESMTP id 917548FC13;
	Sun, 10 Aug 2008 22:55:37 +0000 (UTC) (envelope-from imp@bsdimp.com)
Received: from localhost (localhost [127.0.0.1])
	by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7AMrDsQ095398;
	Sun, 10 Aug 2008 16:53:13 -0600 (MDT) (envelope-from imp@bsdimp.com)
Date: Sun, 10 Aug 2008 16:53:33 -0600 (MDT)
Message-Id: <20080810.165333.232928772.imp@bsdimp.com>
To: jhb@FreeBSD.org
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <200808091637.33820.jhb@freebsd.org>
References: <200808091637.33820.jhb@freebsd.org>
X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: arch@FreeBSD.org
Subject: Re: Make MOD_QUIESCE a bit more useful..
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2008 22:55:37 -0000

In message: <200808091637.33820.jhb@freebsd.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: So currently the MOD_QUIESCE event is posted to a module when unloading a kld 
: so it can veto non-forced unloads.  However, the current implementation in 
: the kernel linker is to run through all the modules in a file, posting 
: MOD_QUIESCE followed by MOD_UNLOAD on each module serially.  Thus, if you 
: have multiple modules in a single kld and one of the modules veto's an unload 
: request via MOD_QUIESCE, you don't know as the module author if any of your 
: modules were unloaded via MOD_UNLOAD or not.  I think a better approach would 
: be to change the kernel linker to invoke MOD_QUIESCE on all modules in a 
: single pass first.  If none of those fail (or it's a forced unload), then it 
: can do a second pass invoking MOD_UNLOAD on all the modules.

That sounds great to me.  I'm a bit surprised it is implemented the
way you say...

Warner