- Expose intel_code_t and amd_code_t enums - they are no longer
limited to just recog_{intel,amd}.c.
- Add libcpuid_internal.h lists those enums and provides the,
cpu_ident_internal() function, which is the same as cpu_identify(),
but also has a third parameter - a internal_id_info_t structure,
which holds detection internals.
All of this is intended to be used in rdmsr, which needs to know
specifics on what CPU it is running.
Also add a comment about the upcoming version 0.2.3. A date is not
stated, as this will be done when the actual release happens (and
I will collect any further patches up to that moment). I expect the
release to be over the next weekend.
rdmsr.c:616:10: warning: comparison of 0 <= unsigned expression is always true [-Wtautological-compare]
if(0 <= val && val <= 7) { // Support 8 P-states
~ ^ ~~~
rdmsr.c:572:8: warning: variable 'val' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if(!multiplier)
^~~~~~~~~~~
rdmsr.c:574:8: note: uninitialized use occurs here
if(val > 0) {
^~~
rdmsr.c:572:5: note: remove the 'if' if its condition is always true
if(!multiplier)
^~~~~~~~~~~~~~~
rdmsr.c:541:14: note: initialize the variable 'val' to silence this warning
uint64_t val;
^
= 0
2 warnings generated.
Tested on GhostBSD (based on FreeBSD)
It should work on DragonFlyBSD (the cpuctl driver has been ported from FreeBSD)
The situation for OpenBSD and NetBSD is not clear ; not supported
The detected intel brand code and model code (arbitrary numbers,
related to the detection algorithm) are printed at verbosiness level
2 or higher. You can see them with `cpuid_tool --all -vv` (if running
on an Intel CPU), or, generally, when decoding Intel CPU data, e.g.
`cpuid_tool --load=tests/intel/nehalem/bloomfield.test --all -vv`.
According to wikipedia, cpu-world and some cpu-z screenshots, these processors
do have a code name and it's willamette, northwood, prescott or cedar mill
Signed-off-by: Veselin Georgiev <anrieff@gmail.com>
msrdriver.c was forgotten from Makefile.am, under the assumption that
autotools are used under *nix only. This is not true, as one could use
MinGW or cygwin.
On Windows, we don't have the API that Linux provides, which can be used
to query MSRs of particular CPU cores. However, the same behaviour can be
emulated. Say that the driver handle object also stores 'dedicated thread
index'. When you call 'cpu_msr_driver_open()', this index is set to -1,
so further API functions do not force which core should be executing
RDMSR code. I.e. "I don't care on which core I run".
However, if this is non-negative number, the subsequent
functions like cpu_rdmsr() are forced to pass through this core by
using temporary affinity mask.
