> However, there is a good deal of conditional goop that runs when you are
> using the GENERIC kernel. I'd recommend building one with only "options
> SUN4C" in your case; removing the SUN4/SUN4M options will speed up things
> like pmap (and thus VM).

Did this when I removed cgthree, cgsix, etc.  Thought I was only removing
device drivers that would not probe anyway.  Glad to hear that it does a
bit more than that. 8)  (My config file is 149 lines as opposed to my
copy of GENERIC which is 285 lines BTW.)

> I suppose it would be possible to have options to specifically enable only
> one version of the code for various CPU revisions, although I'm not sure
> what that will buy you; most of the weirdness is off the common case code
> paths (I mean, if you've got an async. memory fault, saving 10 cycles or so
> is not very useful...).

I'm not one to bother with saving 3 cycles every 5 minutes, or
complain if someone else doesn't either. 8)  I just read the comments
about trap management in the generic kernel, and wondered how much
the non-generic kernels suffered by using the same code.  I thught it
would take more changes is the config file than it actually does.

> Well, the certainly don't run the GENERIC kernel. Hack out support for
> other machines, devices you don't use, etc. from your config file; remove
> debugging/diagnostic options. The GENERIC kernels tend to be large and
> slow, but I think it is important and a Good Thing that they exist and will
> boot on lots of machines...right now the same binary will boot everything
> from a lowly Sun4 up to a fancy Sun4m. A lot of the work on the sun4m port 
> was getting this to work--not a trivial task when you want the same kernel
> to support two rather different MMUs!

I think I understand how much of a miracle that is, and how important
it is.  Thanks Aaron and Jason for putting my fears to rest.  And
thanks for making the non-generic changes so easy that I had done
it (correctly!) without even knowing it!

Jon Buller