>> /proc/cpuinfo is supposed to report CPU information, not kernel
>> bug-detection capabilities, IMNSHO. A normal Linux user with a
>> non-Intel x86 would prefer to see a "clean" cpuinfo, without all
>> the Intel-only bugs. Kernel bug-detection capabilities could be
>> listed on another screen.
> /proc/cpuinfo is not intended for reading _only_ by human users
> (who can see all detected CPU bugs during system boot anyway), but
> also for parsing by programs which need to know whether they can
> rely on the CPU not having the specific bug. It seems obvious to me
> that missing bug info should mean `bug not known to this kernel'
> rather than `bug not present', so that the apps can get all info
> they need at once without having to remember which kernels know the
> bug in question or having to parse yet another file.
Am I misunderstanding what's going on then?
As I understand it, all the bugs listed in /proc/cpuinfo HAVE A
WORKAROUND INSTALLED, so that ANY program trying to activate that bug
MUST fail to do so. As a result, the ONLY meaning that ANY program can
take from a particular processor bug NOT being listed in /proc/cpuinfo
is "Ah, this machine doesn't have a workaround for bug X, so I can use
it to crash this machine" which is the sort of reasoning that VIRUS
programs tend to use and isn't applicable for anything else...
>> BTW TSC calibration in the setup code would allow showing MHz
>> rating in /proc/cpuinfo, so people would stop wondering why they
>> get bogomips such and such everytime a new x86 processor comes
> This would be interesting, but remember that CPU clock speed need
> not be equal TSC frequency.
Is that relevant?
As I see it, there must be a FIXED relationship between CPU clock
speed and TSC frequency, simply due to the fact that anything else
would mean that some sort of random number generator was present.
Remembering the sort of lengths Linux goes to to generate random
numbers, I would find that VERY hard to believe...
Best wishes from Riley.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org