The above was exactly what I meant by being messy and not having a good
control over capabilities, so I think it's a perfect example.
The fact is, we've historically NOT had a good way of indicating which
features the kernel can try to take advantage of. This is something
that 2.4.0 tries to fix - to have everything in one central place with
no way to get mixed up about whether the CPU has some feature or not.
And then export that single source knowledge through /proc/cpuinfo.
I happen to believe that it's a big advantage to have just a single
source of capability data, AND to have that capability data be available
to user mode - with no way for the user to be confused ("But
/proc/cpuinfo _said_ that the kernel had FXSR, why can't I use it?").
Andreas argument was that earlier kernels weren't consistent, and as
such we shouldn't even bother to try to make newer kernels consistent.
We would be better off reporting our internal inconsistencies the way
earlier kernels did - the kernel would be confusing, but at least it
would be consistently confusing ;)
I don't buy that argument. I don't care that we got details like this
wrong before.
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/