> Rather than using words like "good" or "bad", if you state your concerns
> in terms of cause and effect, and let the goodness or badness of those
> effects speak for themselves, people who read your posting will better
> understand the dynamics of the problem your are describing.
Fair enough. Here is my concern: suppose someone builds a kernel with
the feature disabled. Then they reconfigure and add support for this
feature as a module and 'make modules'. The resulting module won't run
on their old kernel, because the resident kernel needs to be rebuilt
when certain modules change.
More generally, I'm concerned that the resident kernel should not vary
depending on what *modules* are built or not.
> Speed tends to be a particularly important metric for math, even
> software math emulation on a 386, unlike, say, with the code Advanced
> Power Management or control of the keyboard lights.
Looking at your patch, it makes these tests for things like
math-not-present traps and ptrace interactions with fpu. I don't
think these are important to anyone's benchmark, are they?
> So, I think the relatively small complexity increase is
> worth the benefit to users who really want FPU emulation to go fast
> (probably people running donated used computers in school, or trying
> to build minimum cost embedded devices).
I'm advocating taking the CONFIG_MATH_EMU_MODULE stuff out and having
these tests all the time. That will not hurt performance at all,
ever, for the emulation case. It will hurt performance for machines
with no emulation support who make the test. But these machines don't
get math-not-present traps anyways.
Regards,
Michael Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu