On Thu, 26 Oct 2000, Andrea Arcangeli wrote:
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > I've made a few correctness changes to this code. Items that needed to be
> > corrected for include the facts that the XMM feature bit is an Intel specific
> > bit that other vendors may use for other things, so you need to test vendor ==
> ^^^
> Note that they shouldn't do that! I would consider a very bad thing if they
> goes out of sync on those bits.
Indeed.
Let's face it. People who don't follow the intel ordering of bits are
_buggy_. And yes, there are tons of buggy chips out there (mainly from
AMD, but I'll refrain from throwing _too_ many stones in case somebody
else ends up with similar bugs in the future ;). And yes, some of those
bugs are even explainable (ie AMD wanted to do their own features, and at
the time Intel didn't reserve those bits).
But whatever the excuses are, it is NOT VALID to not honour the feature
bits. You should NOT have to do something stupid like
if (vendor == intel)
if feature in intel_feature_flags
else if (vendor == ..)
...
just to test a simple feature.
You should do something like
if (X86_FEATURE_SEP & feature)
it claims fast system calls..
and then the _setup_ code is supposed to find bugs, and fix them up.
And the "standard" features are the ones Intel exports. End of story.
Everybody else gets to be re-ordered until they look like intel.
Now, things like 3dnow etc extensions that Intel isn't likely to ever
support can be handled quite well with this approach, thank you very much.
The cpuid "feature" field on x86 is 32-bit. We'll make the kernel feature
fields be 64 bits or more. End of story. And then we move the 3dnow
feature bit up beyond the 32nd bit (or up beyond the 64th bit or wahtever,
in case we start using extended intel bit numbers etc).
The whole _point_ of the feature bitmap is that you don't care about the
vendor, the CPU level, or the phase of the moon. Anybody arguing that you
should check vendor information does not understand what the feature
bitmap is all about, and should be forced to go back to the bad old times
when you had to check the stepping levels etc to figure out what the CPU's
could do.
Note how this also goes for intel and clone 386 and 486 CPU's from before
cpuid: we can fix up the feature bitmap even if they don't even _have_
cpuid, at setup time. So that we forever after can just test the feature
bitmap and be done with it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:18 EST