> In a number of different messages, Chris Demetriou writes:
> >And all of a sudden, tracebacks and post-mortem debugging become so
> >much less useful and/or harder...
> 
> Uh, so, if kernel coredumps don't write out the kernel text,
> change them so they do :).  For the class of routines being
> discussed, we're talking about hand-coded assembler anyway.
> I think this objection is simply red herring.

Yes, and modify the symbol handling inr your kernel debuggers so that
it knows that this special space is going to be 'bcopy_foo' instead,
and ...  "no."

Or does the kernel hacker trying to do the debugging just Have To Know
the Sacred Magic(TM)?


> To put it another way: if we _could_ support dynamically-configuring
> kernels that tune themselves to the available hardware, and avoid the
> need for hand-tuned kernel configurations, why _not_ do so?  
> I honestly don't see why Chris' argument about ``machine-specific
> kernels'' applies here, but not to, for example, the change to
> dynamically size "nkpde" on NetBSD/i386, instead of requiring that
> it be set via a configuration-file option.  Hmmmmn?

This is a performance tweak, and one that doesn't even gain you much
in the case you describe.

You can get perfectly good performance -- differing only by the cost
of an indirect jump -- with a GENERIC kernel, with no special hacks
whatsoever.  If you want optimally-tuned performance, you'll be
compiling a kernel for your hardware anyway (e.g. to get rid of
support for components that you don't need), in which case you, as a
user, get the optimized version "for free," still with no special
hacks.

Why is the special hack necessary?  Let the user decide whether they'd
like to pay a (slight!) cost for the functionality of a GENERIC
kernel, and be done with it.


Your comparison to NKPDE is from space.  NKPDE isn't a performance
item; if it's not big enough, machines will not boot.  If it's too
big, and not dynamically trimmed, then again you run the risk of
making small-memory machines incapable of booting.

A correct comparison would be something like:

NKPDE is a variable in GENERIC kernels, but it can be hard-wired (and
you probably would see a very slight performance gain from this!) and
compiled in as a constant/#define if the user so desires.

However, for the NKPDE case, that "slight performance gain" is, in my
opinion, not even worth discussing such a change for.


> Chris, your arguments seem to boil down to ``I just don't like
> this''. Not to say that's not a defensible viewpoint; but the
> arguments you're using to support that view don't appear to hold
> much water.

Actually, there are several reasons, one of which _is_ "I just don't
like it."  I've think stated a few reasons that i thought it was inappropriate,
and why "i just don't like it," though, and i don't think you're
doing them justice.  In a nutshell, they are:


(1) it makes the code harder to debug,

(2) it makes writing/using the code harder, and makes it harder to
understand,

(3) it doesn't buy you very much at all over another method that i've
suggested (i.e. it buys you the overhead of exactly one indirect jump,
per call to something which is going to be copying or zeroing a page
of memory), and

(4) Any and all performance benefit that you can get from this
technique you can get from another technique which is time-honored and
which has a well-known and well-accepted place in our kernel, and
which doesn't involve any special trickery.

(5) Finally, depending on implementation, it might waste (a small
amount of 8-) space.


I consider self-modifying code to be a last resort.  When you need to
squeeze that last bit of performance out of a piece of code, because
you've got some important requirement you have to meet that you can't
meet any other way.  I've written self-modifying code, and have even
seen some really "cool" uses of it in modern kernels (which would have
been avoided if said modern kernels' vendors' compilers supported
inlining 8-).  However, I think that in a general-purpose kernel like
the NetBSD kernel, it is a tool of last resort.  Given that, and given
that this is _not_ a "last resort," i don't think it's appropriate
here.




cgd