From owner-p4-projects@FreeBSD.ORG Fri Aug 7 12:44:46 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C126B10656A7; Fri, 7 Aug 2009 12:44:45 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 767DD1065680; Fri, 7 Aug 2009 12:44:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 30EF28FC20; Fri, 7 Aug 2009 12:44:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BB70146B2A; Fri, 7 Aug 2009 08:44:44 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1990B8A0AD; Fri, 7 Aug 2009 08:44:44 -0400 (EDT) From: John Baldwin To: Julian Elischer Date: Fri, 7 Aug 2009 08:41:12 -0400 User-Agent: KMail/1.9.7 References: <200908061404.n76E4IIF048503@repoman.freebsd.org> <200908061108.42372.jhb@freebsd.org> <4A7AF3D9.6080601@elischer.org> In-Reply-To: <4A7AF3D9.6080601@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908070841.12785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 07 Aug 2009 08:44:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Julian Elischer , Perforce Change Reviews , Marko Zec Subject: Re: PERFORCE change 167065 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:44:47 -0000 On Thursday 06 August 2009 11:16:41 am Julian Elischer wrote: > John Baldwin wrote: > > On Thursday 06 August 2009 10:04:18 am Marko Zec wrote: > >> http://perforce.freebsd.org/chv.cgi?CH=167065 > >> > >> Change 167065 by zec@zec_tpx32 on 2009/08/06 14:03:58 > >> > >> Merge Julian's updates to V_ instructions document. > >> Submitted by: julian > >> > >> Affected files ... > >> > >> .. //depot/projects/vimage/porting_to_vimage.txt#10 edit > >> > >> Differences ... > >> > >> ==== //depot/projects/vimage/porting_to_vimage.txt#10 (text+ko) ==== > >> > >> -#endif /* !_FOO_VFOO_H_ */ > >> -========================================================= > >> +On BOOT, the order of evaluation will be: > >> + In a NON-VIMAGE kernel where the module is compiled: > >> + MODEVENT, SYSINIT and VNET_SYSINIT both runm with order defined by > > their > >> + order declarations. {good foot shooting aterial if you get it wrong!} > >> > >> + In a VIMAGE kernel where the module is compiled: > >> + MODEVNET, SYSINIT and VNET_SYSINIT both runm with order defined by > > their > >> + order declarations. AND in addition, the VNET_SYSINIT being > >> + repeated once for every new jail/vnet. > >> > >> +On loading a vnet enabled kernel module after boot: > >> + MODEVENT("event = load"); > >> + SYSINIT() > >> + VNET_SYSINIT() for every existing jail > >> + AND in addition, VNET_SYSINIT being called for each new jail > > created. > >> > >> +On unloading of module: > >> + MODEVENT("event = quiesce") > >> + MODEVENT("event = unload") > >> + VNET_SYSUNINIT called for every jail/vnet > >> + SYSUNINIT > >> > >> +On system shutdown: > >> + effectively the same as unload > >> + {with exception of modevent?} > > > > On system shutdown MOD_SHUTDOWN is the only MODEVENT handler invoked. > > > >> +NOTICE that while the order of the SYSINIT and VNET_SYSINIT is reversed > > from > >> +that of SYSUNINIT and VNET_SYSUNINIT, MODEVENTS do not follow > >> +this rule and thus it is dangerous to initialise and uninitialise > >> +things which are order dependent using MODEVENTs. > > > > This is no longer true. MOD_QUIESCE and MOD_UNLOAD events now run in the > > reverse of the order that MOD_LOAD is invoked for a given kld during > > kldunload. This is true in both 7 and 8 now for several months. > > I meant the order within the entries for the same module. > Since MODEVENT is called first during load, it would, by the > assumption that everything is reversed easy to assume that MODEVENT > is called AFTER the SYSINITS during unload. This is in fact not the > case, and I have the scars to prove it. > It might be make some sense if the "QUIESCE" was called before the > SYSINIT/SYSUNINIT and the UNLOAD called after.. with a millisecond > sleep between them. I'm not sure you need the millisecond sleep. This is a bit tricky to resolve and is a general problem with mixing module events with sysuninit. I'm not really entirely sure what the best answer to that is aside from documenting it as such for now. -- John Baldwin