afexists()

[Doug Barton]

On 05/31/2011 21:04, Hiroki Sato wrote:
> Doug Barton<dougb at FreeBSD.org>  wrote
>    in<4DE588B4.7090908 at 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/