Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> 
> Note that there was a precise reason for not implementing it as the TSC disable
> (infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
> The reason is that the way TSC gets disabled breaks /proc/cpuinfo.

No.

It FIXES /proc/cpuinfo.

Your alternative patch is the thing that breaks.

We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
FSXR/XMM to not exist. That is true information, and is in fact something
that install scripts etc can find extremely useful.

In particular, imagine an installation script that wants to install the
proper optimized version of a library on a machine. How is it supposed to
know whether it should use the mmx version, the xmm version, or the
integer version?

This is _exactly_ the kind of thing that /proc/cpuinfo was supposed to be
able to deal with, and that means that if the kernel doesn't like to use
xmm for some reason (ie the user explicitly told it to), then it shouldn't
show up in /proc/cpuinfo - because on that machine XMM simply does not
exist as far as user-land is concerned.

Similarly, when we disable TSC, it's also telling user-land that this
machine does not appear to have a working TSC for some reason. User-land
applications may also care about the fact that TSC seems to skip time if
the machine is idle etc (which was apparently the problem with some broken
Cyrix chips).

After all, a user can always do a "cpuid" to get to know what the CPU
itself reports. /proc/cpuinfo is supposed to be a higher-level interface,
where the buggy bits have been removed or renamed (ie AMD extensions are
properly renamed and can be easily recognized as such, without each
user-mode application having to know about the magic meaning of bits in
"cpuid" on different machines).

		Linus