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

[Jun Sun <jsun@mvista.com>]

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