> 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
Its tricky to do so, some of them were not even documented. And one of them
(SEP) changed in the undocumented phase from one version of SYSCALL to
another (now documented one)
> 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.
You still do. In fact your example SEP specifically requires this due to
Intel specification changes in the undocumented=->documented versions
Alan
On Fri, 27 Oct 2000, Alan Cox wrote:
> > 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.
>
> You still do. In fact your example SEP specifically requires this due to
> Intel specification changes in the undocumented=->documented versions
NO.
Go back. Read ym email. Realize that you do this ONCE. At setup time.
You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
bit. You should not have to test stepping levels in normal use: that
invariably causes problems when there are more than one CPU that has some
feature.
It is insidious. It starts out as something simple like
if (stepping < 5) {
...
}
and everybody thinks it is cool. Until somebody notices that it should be
if (vendor == intel && stepping < 5) {
...
}
and it appears to work again, until it turns out that Cyrix has the same
issue, and then it ends up being the test from hell, where different
vendor tests all clash, and it gets increasingly difficult to add a new
thing later on sanely.
In contrast, having the test be
if (feature & SEPNEW) {
...
}
your test is simplified, easier to read and understand, AND it is much
easier to account for different vendors who have different stepping levels
etc. Especially as some vendors need setup code for the thing to work at
all, so it's not even stepping levels, it's stepping levels PLUS some
certain magic sequence that must have been done to initialize the thing.
No thank you. We'll just require fixed feature flags. Which can be turned
on as the features are enabled.
Linus
> Go back. Read ym email. Realize that you do this ONCE. At setup time.
(I've got about 2000 to read after this jaunt so I may have missed some)
> You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
> bit. You should not have to test stepping levels in normal use: that
> invariably causes problems when there are more than one CPU that has some
> feature.
Agree
> if (vendor == intel && stepping < 5) {
> ...
> }
>
> and it appears to work again, until it turns out that Cyrix has the same
> issue, and then it ends up being the test from hell, where different
> vendor tests all clash, and it gets increasingly difficult to add a new
> thing later on sanely.
And you end up with mtrr.c
> No thank you. We'll just require fixed feature flags. Which can be turned
> on as the features are enabled.
That seems sensible
Followup to: <[email protected]>
By author: Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > and it appears to work again, until it turns out that Cyrix has the same
> > issue, and then it ends up being the test from hell, where different
> > vendor tests all clash, and it gets increasingly difficult to add a new
> > thing later on sanely.
>
> And you end up with mtrr.c
>
Indeed.
>
> > No thank you. We'll just require fixed feature flags. Which can be turned
> > on as the features are enabled.
>
> That seems sensible
>
I'm working on the patch right now.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt