On Sat, 14 Dec 1996 16:03:18 -0800 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > 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.

Actually, in that forum you _didn't_ mention exception handling on the
MIPS (although you did mention VMS :-).  One thing I will point out...
In that mail you also said, and I quote:

   The maintenance headaches of low-level self-modifying code are obvious.

...to which I say "Exactly."  I don't want to be debugging some bit
of code, realizing "Oh, this code modifies itself... Whee, fun!"

 > 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.

I don't like that approach... Ay "my" site, I like to rip out all the
drivers that I know I'm not going to use on a given machine.  We
typically have "classes" of machines:

	LESSER_VAMPIRE	i486 EISA machines with same hardware used as
			workstations, build servers
	VAMPIRE		P6 PCI machines with same hardware used as
			devel platforms, build servers
	WHITNEY		Kernel for the cluster machines (same hardware)

...etc.  We rip out the unneeded drivers, set certain parameters
(like my build server gets a bigger buffer cache, etc.)  Machines
in the same "class" get the same kernel... But are, in all other
ways, tuned for that class.

 > 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?

Mostly because the previous behavior was a bug in two ways:

	(a) The default value didn't work at _all_ on many systems,
	    to the point where you couldn't "tune", and

	(b) the default value was not overrideable in the kernel
	    configuration file.

You'll note that you can now set "options NKPDE=foo" in your
kernel config file, and it will work :-)

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

...and how do you do that?

#ifndef GENERIC
	/* loop that modified code here */
#endif

??  Seems ... lame.

 > 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.

Not necessarily true.  In this case, we're talking about the m68k ports,
and so far, all the m68k workers have liked what JT and I have been
doing :-)  I mean, on a sun3/60, you really do need to optimize things
like page zero/copy :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939