>> It would be better to have ONE line with cpu_bugs, and show bugs
>> which are present, or something similar like this :
>> cpu_bugs : f00f
>> It's very easy to implement, only modifiy some line in
>> arch/i386/kernel/setup.c (it's easy for me too, surprise ! :)
>> get_cpuinfo function.
> Actually it isn't better, as it leaves out a key piece of
> information: it makes it no longer possible to distinguish between
> a bug which isn't present, and a bug which a certain kernel doesn't
> know how to detect.
Personally, I'd like to see /proc/cpuinfo split up something like the
following:
Q> % cd /proc
Q> % ls -lG cpu* | tr -s ' '
Q> -r--r--r-- 1 root 0 Dec 8 11:15 cpuinfo
Q>
Q> cpu:
Q> total 0
Q> -r--r--r-- 1 root 0 Dec 8 11:15 bugs
Q> -r--r--r-- 1 root 0 Dec 8 11:15 model
Q> -r--r--r-- 1 root 0 Dec 8 11:15 performance
Q> % cd cpu
Q> % for Z in * ; do echo ; echo $Z: ; cat $Z | sort ; done
Q>
Q> bugs:
Q> f00f_bug : yes
Q> fdiv_bug : no
Q> hlt_bug : no
Q>
Q> model:
Q> cpu : 586
Q> cpuid : yes
Q> flags : fpu vme de pse tsc msr mce cx8
Q> fpu : yes
Q> fpu_exception : yes
Q> model : Pentium 75+
Q> processor : 0
Q> stepping : 6
Q> vendor_id : GenuineIntel
Q> wp : yes
Q>
Q> performance:
Q> bogomips : 47.92
Q> %
As shown, I would leave /proc/cpuinfo in for the moment, so those
utilities referring to it can still work, but I would mark it as
"depreciated and likely to vanish" so as to encourage the authors to
modify their programs appropriately.
However, this is probably all wishful thinking...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/