"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
> responses
> > 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
in ptrace.c.
. 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
implementation.
b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
application
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
yet.
Are we confident we can do a clean run-time detection of all existing CPUs?
Jun
|