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. 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. 2. run-time detection approach: CPU probing code probes CPU and sets has_fpu field in the mips_cpu structure. All FPU related code is on a conditional branch based on has_fpu value. Run-time Detection Approach --------------------------- Plus: . the same kernel image can run on CPUs either with or without a FPU. Minus: . run-time overhead a) cpu detection b) conditional checking for FPU related code . extra code size (FPU detection and conditional branch for FPU related code) . do we have a reliable detection method without any help from CONFIG (I am not 100% sure here) Config Option Approach ---------------------- Plus: . The reverse of the minus for run-time detection approach Minus: . The same kernel image cannot run on CPUs both with and without a FPU. My Conclusion -------------- 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) Jun
