📝 Document the CPU identification table and the rule that keeps it honest - #34
Open
manupawickramasinghe wants to merge 1 commit into
Open
Conversation
…nest The codename table restored in #33 is a competitive feature and a fragile one, and neither fact was written down anywhere outside the code. README gains a differentiator paragraph: every entry is traceable to `intel-family.h` or libcpuid's `recog_amd.c`, and LibreHardwareMonitor's own table matches only families 06h and 0Fh, so Intel's 12h/13h parts are unreachable for it. The System Summary bullet now says what that panel actually shows, including the decoded SMBIOS memory type. app/README gains the two rules a contributor adding a CPU needs: cite the source or fall back to a generation, and match a single model rather than a high-nibble range — the range mistake is what put an EPYC codename on three Threadrippers. TODO records the ExtendedModel deviation at sysinfo.rs:49, which was found during review and deliberately left unfixed. It only existed in a PR description before this, which does not survive the merge. PROJECT_SUMMARY's sysinfo.rs line said ~427 lines; it is ~1300. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018o7QQhLP2tNHG62b1d2q7R
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation only. No code changes — zero lines under
app/src/, no testor CI impact.
Stacked on #33. GitHub retargets this to
masterautomatically once #33 merges.Why
#33 restored the CPUID → microarchitecture codename table and fixed three
Threadrippers that were reporting an EPYC codename. Two things came out of that
work that lived nowhere but the code and a PR description:
CPU had no way to know.
A PR description does not survive the merge. These belong in the repo.
What changed
README.mdapp/README.mdTODO.mdsysinfo.rs:49under Code qualityapp/PROJECT_SUMMARY.mdsysinfo.rssaid "~427 lines" (it is ~1300); System Summary row now mentions the codename and memory-type decodeThe competitive claim, and why it is safe to make
The README now states that LibreHardwareMonitor's own CPU table matches only
families
06hand0Fh, so Intel's Nova Lake (12h) and Diamond Rapids(
13h) are structurally unreachable for it. That was verified by readingLibreHardwareMonitorLib/Hardware/Cpu/IntelCpu.csupstream, not assumed.It is scoped to CPU identification, which is SensorView's own CPUID decode
in
sysinfo.rs. It deliberately does not claim any advantage in sensorcoverage, which on Windows comes from LHM.
The rule being written down
A
0x00..=0x0frange written around one sourced model silently swallows itsneighbours. AMD families 17h, 19h and 1Ah each ship a Threadripper at model
08h, immediately beside the server part at01h/02h— which is how threeworkstation CPUs came to report an EPYC codename.
app/README.mdnow statesthe rule, and the
a_threadripper_is_not_an_epyctest enforces it.Also recorded:
intel-family.hwrites family numbers in decimal, soIFM(18, …)is family 12h, not 18h. That mistake reads as a plausible entrybecause 19h is AMD's Zen 3/Zen 4 family.
Verification
Docs-only, so nothing to run — but for completeness, #33 is green on all four
platform builds (windows/nsis, macos/dmg, ubuntu/deb+appimage, ubuntu-arm/deb)
with 172 tests passing and
cargo clippy --all-targets -- -D warningsclean.🤖 Generated with Claude Code
https://claude.ai/code/session_018o7QQhLP2tNHG62b1d2q7R