Chris G Demetriou wrote:
> 
> My thoughts on the matter:
> 
> If you're tailoring a kernel to a specific system, and that's why you
> want to use "options BUFCACHE", why not just wire a certain number of
> buffers/pages via NBUF/BUFPAGES?  (how often does your memory size
> change?  since they're patchable, you don't have to build a new
> kernel, even...)

This is what I end up doing, though I had to do a bit of digging to
figure this out.  Then I needed to change NKPDE or the box would die.
This was all "not obvious" to the average joe.  Even figuring out
how to get RAM above 16MB (usually on EISA machines) accessible
wasn't obvious until the 'options EXTMEM_SIZE' feature.  So, I'm
basically just saying that NBUF/BUFPAGES is fine with me, but it
should be documented in the config files. (or _a_ config file)
The same goes for NMBCLUSTERS (and prolly a few others I don't know
about!)
What would be nice, is an 'ALL' (or LINT like FreeBSD?) kernel config
for _each_ arch that lists all possible options with comments.
(a lot like Jason did for sparc) 

> (In other words, i'm still not convinced that this should be an
> option at all, and that if it should be it's "good enough" as is.  8-)

I agree, if we are adding BUFFERCACHE to implement something similar
to NBUF/BUFPAGES, it will need to be documented to be useful, so why
not just document NBUF/BUFPAGES?  On the other hand, hard-coding
the buffer cache can be real a pain when you pull out some RAM and don't
change the kernel!  (ouch! I've been there)  The ability for it to
dynamically resize (at boot) is a plus.  Perhaps when the NKPDE
problem is fixed, something more dynamic will be implemented.

-Andrew