"Kevin D. Kissell" wrote:
> > I love this topic!
> Well, I'm glad *you're* having fun! ;-)
> > Instead of replying to 10 different emails, I decide to sort out my best
> > understanding of this topic and list them here, including some of MY
> > to some of the issues.
> > Definition:
> > ------------
> > 1. Config option approach :
> > In the kernel config menu, one picks one or more CPUs. One also specifies
> > whether the CPU(s) have a FPU.
> > All FPU related code in kernel is configured in or out based on the CONFIG
> > setting.
> As has been noted in other messages in this exchange, whether one
> has an FPU or not isn't really the determining factor in including FP
> support code in the kernel. The bulk of it is the emulator, and the
> emulator needs to be there if you want to execute binaries built
> to include MIPS FP instructions, whether in full emulation or using
> the FPU (for the denormal cases, etc.).
That needs a little more explanation.
. When I say "All FPU related code", I really meant FPU code which is not a
part of FPU emaulator. One example is the code in exit_thread()
(arch/mips/process.c) as brough up by flo. I believe there are also such code
. Regarding whether we should have FPU emulator, I think it should be a
separate CONFIG option. It is orthorgal to HAS_FPU option.
In other words, we will have four combinations:
a) HAS_FPU & FPU_EMULATION - which is necessary when FPU is not a full
b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
c) HAS_FPU & !FPU_EMULATION - when FPU is a full implementaion (or use the
old incomplete emaulation?)
d) !HAS_FPU & !FPU_EMULATION - it mandates non-fpu-ful userland (which to me
is perfectly fine)
I start to feel a little "shaky" here as I have not written any FPU code.
Will such a classification make life easier or worse? Is there any
feasibility issue here?
> If you're building kernels for a workstation, that may be
> true. If you're building kernels for a testbed where you're
> swapping CPU modules, it's actually rather nice to have
> a single kernel that boots on any of them. I personally
> find myself in this situation. Or to provide a less lab-oriented
> example, NEC has the R43xx family which have FPUs,
> and Toshiba markets some R49xx parts that are pin-compatible
> but cheaper - because they have no FPU. If I were building
> a Linux-based system around either one, memory permitting,
> I would want to have a kernel that could cope with either of
> them, to simplify the product management problem if I ever
> ended up wanting to cut over from one to the other.
I think this example shifted my bias a little bit, although it has changed it
Are we confident we can do a clean run-time detection of all existing CPUs?