From owner-p4-projects@FreeBSD.ORG Thu Aug 6 15:16:44 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 679911065678; Thu, 6 Aug 2009 15:16:43 +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 0C8521065673 for ; Thu, 6 Aug 2009 15:16:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outt.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id E54768FC1F for ; Thu, 6 Aug 2009 15:16:42 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BC9A422D3; Thu, 6 Aug 2009 08:16:42 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 12C0D2D601A; Thu, 6 Aug 2009 08:16:41 -0700 (PDT) Message-ID: <4A7AF3D9.6080601@elischer.org> Date: Thu, 06 Aug 2009 08:16:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: John Baldwin References: <200908061404.n76E4IIF048503@repoman.freebsd.org> <200908061108.42372.jhb@freebsd.org> In-Reply-To: <200908061108.42372.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 06 Aug 2009 15:16:45 -0000 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. > thanks for the comments.. could you possibly change the doc to suite? I don't have a p4 tree right now.