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.

>(Something like this was actually suggested in another forum
>yesterday(?) by jonathan stone, as well...  And i still dislike it.  8-)

As I noted in that forum, the exception handling on mips CPUs
_requires_ this kind of hackery.  Doing it before may have
desensitized me to the grosser aspects of this.

>Note that this affects only GENERIC kernels.  For machine-specific
>kernels, which people should be using, anyway, in my opinion

There are other opinions.  I use configurations that include all the
devices present at `my' site -- including all the CPUs.  That gives
the flexibility to copy kernels from one machine to another. Not being
able to do that is gross.  The other, historical, reasons for building
machine-specific kernels is/was to get better-tuned values for various
parameters that affect statically-sized arrays.  That is, or should
be, a historical curiosity only.

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?


>GENERIC kernels are used e.g. for distributions.  You don't
>particularly want trickery there.  Also, if somebody's trying to run
>them on a new machine, and gets a crash, you want that crash to be
>absolutely as debuggable as possible, so that if it's a stupid mistake
>you can fix it and not have them testing kernels ad infinitum...

So if it's that big a deal, turn off installation of tuned versions
of bcopy() / whatever  for GENERIC kernels, or on "new" hardware.


>One some architectures, there's really no overhead difference between
>a 'direct' and 'indirect' function call.

And on some CPUs there _is_. (Off-hand, I can't think of any CPU
where the difference between virtual and non-virtual C++ function calls
isn't  measurable).  What's your point, on those machines?


>There's always cpu-cycle
>overhead for comparisons and branches, not to mention the additional
>memory load that they can cause (test

Yes, exactly. The point of the self-modifying-function is to avoid
that, at the cost of a copy, cache-flush, etc.  That cost can be amortized
over 10's of thousands of calls to the functions in question.

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.


Jason Thorpe proposes something else:

>A much better approach is to gave a single function that does the
>comparisons only if configured for multiple CPU variants.  If only
>configured for one, the comparisons aren't there (they're #ifdef'd).

which is  susceptible to causing spaghetti code, especially when
used inside code with copy-register-chunk/copy-long/copy-short/copy-byte 
loops, like bcopy() and friends....

In any case, given how NetBSD works, this isn't likely to happen
unless the relevant portmasters agree on it -- which doesn't seem
likely at the moment.