Re: config option vs. run-time detection (the debate continues ...)

[Jun Sun <jsun@mvista.com>]

"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