Investigate possibilities for a processor backend, or how to do it for the UDev backend.
Added by revision 1194856, but yet to implement: - maxSpeed - canChangeFrequency - instructionSets The number of processor is fetched from the URI itself, I guess this is fine, but just in case...
canChangeFrequency is obtained by HAL from /proc/acpi/processor/CPU{number}/info, by looking at the "throttling control" field. maxSpeed is not set by HAL on Linux (only on FreeBSD).
The content of /sys/devices/LNXSYSTM:00/LNXCPU:XX/sysdev/cpufreq/ (so the sysdev/cpufreq folder from the pristine udev path) is much more reliable for me. For instance /proc is plain lies on my laptop for some reasons. And using this one I get the max speed info easily as well.
Hmm... I have to modprobe acpi_cpufreq to get that folder to appear. I think maybe we should use sysfs (cpufreq) if we can, and fall back to /proc if that fails.
Honestly I'd assume cpufreq to be there, these days it's supposed to be by default and moreover for the frequency and throttling it's likely not going to happen anyway if cpufreq isn't loaded (AFAIK).
(See Review Request for details). After some more research into the distinction between throttling and frequency scaling, I decided that HAL was doing it wrong (or, at least, the HAL Solid backend was reporting misleading information). My latest patch uses cpufreq exclusively for canChangeFrequency(), and cpufreq for preference (with a fallback to /proc/cpuinfo) for maxSpeed(). It still gets vendor and model info through /proc/cpuinfo, as that is not reported through sysfs.
This is fixed with the existing udev backend