From owner-freebsd-rc@FreeBSD.ORG Thu Jun 2 00:05:52 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 407751065672; Thu, 2 Jun 2011 00:05:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 59E20152148; Thu, 2 Jun 2011 00:05:29 +0000 (UTC) Message-ID: <4DE6D3C8.1050503@FreeBSD.org> Date: Wed, 01 Jun 2011 17:05:28 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hiroki Sato References: <4DE55A48.8090508@FreeBSD.org> <4DE588B4.7090908@FreeBSD.org> <20110601.130434.820821962809263631.hrs@allbsd.org> In-Reply-To: <20110601.130434.820821962809263631.hrs@allbsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bz@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: afexists() X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:05:52 -0000 On 05/31/2011 21:04, Hiroki Sato wrote: > Doug Barton wrote > in<4DE588B4.7090908@FreeBSD.org>: > > do> >> Attached is a patch which caches a positive result for support for a > do> >> given address family. I don't think caching negative results is a good > do> >> idea since that could change as the boot progresses. > do> > > do> > Not yet for inet or inet6 (or ipx I think) but atm might be loadable. > do> > Looking ahead that's certainly true though maybe also considering > do> > virtualization maybe. > do> > do> I think it's generally safer not to cache the negative answer, and > do> from what you're saying it sounds like it may add some future-proofing > do> as well. And yes, I did also have VMs in mind, since I'm doing a lot > do> of work in that area atm. > > Caching the results looks good to me, but I think it is rather safer > to keep the results unchanged while a script is running regardless of > the value. This is because the rc.d scripts do not assume afexists() > returns different values in a run (at least at this moment) , and > writing a script to support such a dynamically-changed condition > would be quite difficult. I understand what you're saying, but I'm not sure which is the worse problem. However, since the likelihood of the situation happening are very small, I think leaving it as is for now is the safest alternative. We can deal with any problems if/when they arise. > do> >> I plan to commit this on Friday if there are no objections. > do> > > do> > I am not sure it helps but I see no regression, so if you want, feel > do> > free to go ahead. > do> > do> If you can assume that each call to the sysctl takes 100 ms (which is > do> a WAG for sake of argument), then saving 25 of them will result in us > do> booting 2.5 seconds faster. I'd ultimately like to cut the > do> rc.d-related portion of the boot in half, if not more, so every little > do> bit helps. > > I think it would be great if it is possible to create a wrapper > function for testing and caching. I expects testing kern.features.* > is likely added again to somewhere in rc.d scripts, and adding a long > lines of "[ -n ... ]&& return 0; if sysctl...; fi" each time > degrades readability. I think that's definitely an interesting idea, and I'd love to review patches that implement it. :) Unfortunately I don't have time to do so atm, and would prefer to focus on a specific case where a small optimization leads to a big gain. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/