From owner-freebsd-rc@FreeBSD.ORG Wed Jun 1 04:08:44 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C86E7106566B; Wed, 1 Jun 2011 04:08:44 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 041F48FC08; Wed, 1 Jun 2011 04:08:43 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5148UhW023226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 13:08:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5148S94040746; Wed, 1 Jun 2011 13:08:30 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 01 Jun 2011 13:04:34 +0900 (JST) Message-Id: <20110601.130434.820821962809263631.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4DE588B4.7090908@FreeBSD.org> References: <4DE55A48.8090508@FreeBSD.org> <4DE588B4.7090908@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jun__1_13_04_34_2011_436)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Wed, 01 Jun 2011 13:08:41 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp 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: Wed, 01 Jun 2011 04:08:45 -0000 ----Security_Multipart(Wed_Jun__1_13_04_34_2011_436)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. 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. -- Hiroki ----Security_Multipart(Wed_Jun__1_13_04_34_2011_436)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3lulIACgkQTyzT2CeTzy3ZSACgtZql1JS6zeg1qUJnMANTgr/6 tP4An178sM5zbqjiDFVNnogQDamkHZQ6 =WYlU -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jun__1_13_04_34_2011_436)----