Well, consider it this way: I think it is conceptually just completely
wrong to have a "capability" word, and then despite having a capability
word have something horrible like this:
> if ((boot_cpu_data.x86_capability & 16) && (boot_cpu_data.x86_vendor ==
> X86_VENDOR_CYRIX (boot_cpu_data.x86_model != [5x86Model])) &&
> (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR
> (boot_cpu_data.x86_stepping == 0))) {
That kind of throws away the whole _point_ of using the capability word in
the first place.
If you want to distinguish between
- has no cycle counter
- has a broken cycle counter
- has a cycle counter that works as documented
then that part I have no argument with. HOWEVER, if so, you'd better make
it a new capability or something, because I don't want to have "real"
kernel code having to care. This is something that is very CPU dependent
(and even stepping-dependent), and I don't want to have code all around
the kernel checking for the "random stepping of the day bug".
Let's get this straight: I don't have anything against fixing problems
with buggy CPU's, but workarounds for ugly problems have to at least be
done right.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu