>
> It's worse than you think.
> Distinguishing between XP and MP athlon for example needs
> capability bit testing. (And some XP's _are_ now multiprocessor
> capable, just to confuse the issue some more), so relying on
> the cpuid identity string isn't foolproof.
> (Also, some implementations allow for this string to be changed,
> some folks have it set to "PenguinPowered" and the likes 8-)
>
Sure, but if you do that you're *asking*, in a very literal way, for
your CPU to misidentified. In fact, a major reason for making this
string modifiable is due to certain vendors who hard-code CPUID strings
in their code.
>
> Asides from the above issues, multiple CPUs have the same
> cpuid sometimes, meaning you have to check things like
> cache size as well (though most (all?) of these should
> end up with the same CONFIG_ option iirc, so this shouldn't
> be an issue -- you should check to be sure though)
>
Why -- if it doesn't change anything, all you're doing is making it
confusing when the next derivative appears. Remember that we *do* need,
as much as possible, to be forward compatible with future CPUs.
> x86info's identify.c files should give you a fairly
> comprehensive guide to the various types.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/