From owner-svn-src-all@FreeBSD.ORG Fri Nov 19 21:46:15 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35B861065672; Fri, 19 Nov 2010 21:46:15 +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 E83DB8FC0C; Fri, 19 Nov 2010 21:46:14 +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 84F6B46B2E; Fri, 19 Nov 2010 16:46:14 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A79658A027; Fri, 19 Nov 2010 16:46:13 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Fri, 19 Nov 2010 16:46:11 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201011191943.oAJJhv3i087205@svn.freebsd.org> <201011191621.25520.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011191646.12106.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 19 Nov 2010 16:46:13 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Jung-uk Kim Subject: Re: svn commit: r215544 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 21:46:15 -0000 On Friday, November 19, 2010 4:31:44 pm Attilio Rao wrote: > 2010/11/19 John Baldwin : > > On Friday, November 19, 2010 4:09:28 pm Jung-uk Kim wrote: > >> On Friday 19 November 2010 02:43 pm, Attilio Rao wrote: > >> > Author: attilio > >> > Date: Fri Nov 19 19:43:56 2010 > >> > New Revision: 215544 > >> > URL: http://svn.freebsd.org/changeset/base/215544 > >> > > >> > Log: > >> > Scan the list in reverse order for the shutdown handlers of > >> > loaded modules. This way, when there is a dependency between two > >> > modules, the handler of the latter probed runs first. > >> > > >> > This is a similar approach as the modules are unloaded in the > >> > same linkerfile. > >> > > >> > Sponsored by: Sandvine Incorporated > >> > Submitted by: Nima Misaghian > >> > MFC after: 1 week > >> > >> Hmm... It is not directly related but I was thinking about doing > >> similar things for sys/kern/subr_bus.c. What do you think about the > >> attached patch? > > > > Hmm, the patches for suspend and resume that I had for this took the opposite > > order, they did suspend in forward order, but resume in backwards order. > > Like so: > > > > --- //depot/vendor/freebsd/src/sys/kern/subr_bus.c 2010-11-17 22:30:24.000000000 0000 > > +++ //depot/user/jhb/acpipci/kern/subr_bus.c 2010-11-19 17:19:02.000000000 00 > > @@ -3426,9 +3429,9 @@ > > TAILQ_FOREACH(child, &dev->children, link) { > > error = DEVICE_SUSPEND(child); > > if (error) { > > - for (child2 = TAILQ_FIRST(&dev->children); > > - child2 && child2 != child; > > - child2 = TAILQ_NEXT(child2, link)) > > + for (child2 = TAILQ_PREV(child, device_list, link); > > + child2 != NULL; > > + child2 = TAILQ_PREV(child2, device_list, link)) > > DEVICE_RESUME(child2); > > return (error); > > } > > @@ -3447,7 +3450,7 @@ > > { > > device_t child; > > > > - TAILQ_FOREACH(child, &dev->children, link) { > > + TAILQ_FOREACH_REVERSE(child, &dev->children, device_list, link) { > > DEVICE_RESUME(child); > > /* if resume fails, there's nothing we can usefully do... */ > > } > > > > (Likely mangled whitespace.) > > > > I couldn't convince myself which order was "more" correct for suspend and resume. > > Considering loading in starting point, I think suspend should go in > reverse logic and resume in the same module load logic. > So that dependent modules are suspended first and resumed after. > Don't you agree? These are devices, and the ordering here is the order of sibling devices on a given bus. That is, if you have a PCI bus with two em interfaces, does it really matter if em0 suspends before em1 vs after em1? I think it actually doesn't matter. The passes from the multipass boot probe might make some sense to order on. However, I don't think the order of siblings on a bus is meaningful for suspend and resume (which is why I've never committed the above patches). Specifically, there is no dependency relationship between siblings on a bus. Certain buses may in fact have a dependency order of sorts (vgapci0 comes to mind), but those buses should manage that. There is no generic dependency between siblings that should be encoded into subr_bus.c -- John Baldwin