Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Jun 2011 13:04:34 +0900 (JST)
From:      Hiroki Sato <hrs@FreeBSD.org>
To:        dougb@FreeBSD.org
Cc:        bz@FreeBSD.org, freebsd-rc@FreeBSD.org
Subject:   Re: afexists()
Message-ID:  <20110601.130434.820821962809263631.hrs@allbsd.org>
In-Reply-To: <4DE588B4.7090908@FreeBSD.org>
References:  <4DE55A48.8090508@FreeBSD.org> <F1D28BBA-2956-46FF-A71E-B08CE20BFEDF@FreeBSD.org> <4DE588B4.7090908@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Wed_Jun__1_13_04_34_2011_436)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Doug Barton <dougb@FreeBSD.org> 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)----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110601.130434.820821962809263631.hrs>