[Top] [All Lists]

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

Subject: config option vs. run-time detection (the debate continues ...)
From: Jun Sun <>
Date: Thu, 08 Feb 2001 12:27:33 -0800
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 
(I am
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.

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)


<Prev in Thread] Current Thread [Next in Thread>