I love this topic!
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.
1. Config option approach :
In the kernel config menu, one picks one or more CPUs. One also
whether the CPU(s) have a FPU.
All FPU related code in kernel is configured in or out based on the
2. run-time detection approach:
CPU probing code probes CPU and sets has_fpu field in the mips_cpu
All FPU related code is on a conditional branch based on has_fpu value.
Run-time Detection Approach
. the same kernel image can run on CPUs either with or without a FPU.
. run-time overhead
a) cpu detection
b) conditional checking for FPU related code
. extra code size (FPU detection and conditional branch for FPU related
. do we have a reliable detection method without any help from CONFIG
not 100% sure here)
Config Option Approach
. The reverse of the minus for run-time detection approach
. The same kernel image cannot run on CPUs both with and without a FPU.
Clearly, it is a trade-off decision based how much one values the minuses and
pluses of both approaches.
While I do agree the minus for run-time detection are not serious ones, I
think the minus for config option is even less serious. Having the same
kernel image runs on multiple CPUs is very nice. I just doubt about the
usefulness of requiring the same kernel image to run on CPUs both with a FPU
and without a FPU. Therefore in the light of minus of the run-time detection
approach, I still favor config option.
(aha, I proved my intuition. It is a theory now. :-0)