On Sun, 3 Mar 2002, Thor Lancelot Simon wrote:

: > : That's not true.  I've seen relatively small differences in kernel size
: > : make dramatic differences in packet forwarding performance on crappy
: > : embedded platforms with small or stupidly-designed caches.
: >
: > Kernel size != code path.  The *code* introduced by COMPAT_<number> does not
: > hit performance in any significant way.
:
: That's just false; like all other code, it takes up space, and that can
: really suck.
:
: Since these options are quite simply not useful to whole classes of users,
: and they *do* bloat the kernel, and that *does* hurt performance, we should
: not blindly include them in all of our example configurations; particularly
: not those for small machines!

They're in GENERIC for a reason:  those are "generic" configurations meant
to run with nearly all optional components enabled.  The same argument could
be made for SYSV*, DIAGNOSTIC, and a host of other options that are unneeded
by the majority of users.  Not to mention things that sit in critical code
paths like FFS_EI.

(This is really a matter of differing brain wavelengths further into this
thread.  My response was meant to address your initial comment that "the
impact of COMPAT_<number> should be in a FAQ", implying that somehow
COMPAT_<number> had adverse impact other than just added code size.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/