Messages in this thread |  | | Date | Thu, 26 Oct 2000 08:44:06 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: missing mxcsr initialization |
| |
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/
|  |