[Top] [All Lists]

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

To: "Kevin D. Kissell" <>
Subject: Re: config option vs. run-time detection (the debate continues ...)
From: "Maciej W. Rozycki" <>
Date: Fri, 9 Feb 2001 12:48:10 +0100 (MET)
Cc: Jun Sun <>,
In-reply-to: <021b01c0922e$c8df4440$0deca8c0@Ulysses>
Organization: Technical University of Gdansk
On Fri, 9 Feb 2001, Kevin D. Kissell wrote:

> It's not so much that I doubt the feasibility, I just wonder
> if there's any point to adding the complexity.  As noted
> above, if you're going to support FP-full binaries, you
> have to support the processor model of FPU.  The user
> will be manipulating what he sees as FP registers, and
> all of the state, signal, and context management logic
> associated with them has to be there regardless of whether
> they exist in the CPU or in the kernel.  It's true that there are
> a few paths through the code, the ones that actually load
> and store the FP registers, that are distinct.  Those could
> certainly be suppressed at compile time if you wanted a
> kernel that would never allow a real FPU to be used,
> but the memory savings would be smaller than you seem
> to think.  It's not "HAS_FPU" versus "EMULATOR",
> it's "SUPPORTS_FP" and "HAS_FPU".

 Let me remind the actual problem the discussion started from was whether
we want to hardcode FP hw presence based on a CPU identification or to
check for it explicitly.  I hope we agree the latter is saner.

 But the code that needs to know whether there is a real FPU present is
indeed minimal (as it should be) thus the gain from removing the detection
altogether in favour to a config option is at least questionable if not

> My own recommendation would be to either have
> full FP support for binaries or none at all.  If someone
> really wants to put the FPU-specific assembler
> routines under a different conditional, that's cool, but
> the configuration options should be such that the
> (c) cannot be generated by the config scripts.

 I think I may research what the gain from leaving parts of the FPU
emulator apart would be for systems that have FP hw.  It's not a priority
task for me at the moment -- the current configuration works and having
unused code in a running kernel is ugly but non-fatal. 


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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