Yi Yang wrote:
It's broken, because it doesn't take into account the fact that Intel
broke CPUID level 4 and made it "repeating" (neither did the cpuid char
device, because it predated the Intel braindamage; I've had a patch for
it privately for a while, but didn't push it upstream because paravirt
broke it royally and I wanted the situation to settle down.)
It's broken, because the algorithm used to determine valid CPUID levels
is incorrect; it fails to recognize any CPUID levels other than the main
Intel and AMD ones, e.g. the Transmeta 0x8086xxxx (and sometimes more)
and VIA 0xc000xxxx levels.
Thank you for pointing out these issues, i think we can let users input
any cpuid level and output the corresponding cpuid, in this way we can
avoid to consider cpu differences and left this to userspace. We can
also consider all the x86 platforms to do cpuid for every one.
It's broken, because it is better for the userspace extractor to have
this logic than to stuff it into the kernel, where it sits hogging
unswappable memory at all times.
It seems not to be very appropriate to let user space consider hardware
details. /proc/cpuinfo should be an example to justify this.
/proc/cpuinfo represents what the kernel needs to know, so it reflects
the kernel's interpretation of CPUID. There is no reason to interpret
things in the kernel that the kernel doesn't need.
Is there any user application using /dev/cpu/*/cpuid? if no, i think it
is feasible to provide an interface in the kernel.
Yes. It's called x86info, I believe.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/