>Kernel questions:
>1) If you have a 486DX with a math fpu, do you want or need the npx line
>   in the kernel config?

Definately.  If you don't have it, then I don't believe your math coprocessor
will work.

>2) If you have this line, will fpu instructions invoke it, despite the
>   fact you have hardware to do it?

Yes, but since you say "despite", I think that you've got things backwards.
You want the npx device if you have a math coprocessor, and you probably
want MATH_EMULATE if you don't.

>1) Currently, to get the math libraries (libm) to compile right, you
>   must edit the libm makefile.  What is the diff here?
>   If you do not use i387 in this makefile, does it do emulation with
>   integer code or something, or what?  It is somehow unoptimal to
>   simply use the same routines and simply emulate the unimplemented
>   fp instructions in the kernel?

I believe that the answer is that our current kernel FPU emulator is buggy.
I think this is still the case, but I'm not sure.  Naturally, we don't
want to give someone wrong answers if you don't have a math coprocessor.
But it _does_ kinda suck that you have to rebuild the math lib if you
want to use the co-processor, where in other OS's, you don't.  It's not
exactly obvious first what's happening, and it leads some people to
believe that NetBSD has really bad FPU performance (which I suppose is
true in one sense, but it's easily fixable).

What I wish was that a libmi387 (or whatever) was distributed with the i386
binary kits, so users could easily switch to using the i387 routines without
downloading the NetBSD library source.

>2) If the answer to #1 above was that we should do integer code emulation
>   in the library routines (or in some other way have the lib routines
>   differ based on the kernel configuration), what is the optimal way
>   to do this?  Should it ask the kernel about its configuration at
>   run-time?  sysctl?

Hmmm.  Would that cause too much overhead?  I dunno.

>   Or should we tie in the kernel generation to library development
>   so that the libraries pick up the kernel configuration details like
>   CPU, etc.

I think that would be evil.

--Ken