os: Processor.describe and ProcessorDescription on x86-64 (OS slice 3, step 2b of #127) #543
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Step 2b of #127 (OS slice 3):
Processor.describe()andProcessorDescriptionon x86-64 Windows, Linux and macOS, assembled from the decoders step 2a landed (#538) and the system's own counts.Why the cut: the rest of step 2 (vendor, model, caches and features of an Arm64 processor from
getauxval(AT_HWCAP),hw.optional.*andIsProcessorFeaturePresent, three new natives or sysctl names, three per-system halves) is a second PR of its own. Only this first part is filed, per the definition of ready; the Arm64 part stays in the epic checklist as step 2c and is filed when this one lands.Design record
docs/design/OS.mdsection 5.2 (Processor.describe,ProcessorDescription), the "As built (step 2a)" note of section 7 ("ProcessorDescription(step 2b) takes that count from the system"), slice 3 of section 10.Scope
ProcessorDescriptioninstd/os/src/processor.trbas in section 5.2 (vendor,model,packages,physicalCores,logicalProcessors,baseFrequency,maximumFrequency,caches,features;with Show, Equals).baseFrequencyandmaximumFrequencyareNonehere; step 3 fills them.Processor.describe(): Result<ProcessorDescription, OsError>: amatch OperatingSystem.currentlike its siblings,Unsupportedarms for FreeBSD and the browser; on Windows, Linux and macOS anArchitecture.currentmatch whose.X64arm readsCpuidDump.read()and whose other arms answerOsError.Unsupported("the processor description", ...)until step 2c replaces them.x86/processor.trb(aCpuidDumpmethod or a static function over a dump and three integers): vendor, brand and features from the dump, caches from the dump,logicalProcessorsandphysicalCoresfrom the system's counts (Processor.logicalCount,physicalCount), because on a hybrid processorcpuidanswers for the core it happens to run on (OS.md 7, as built). Brand string trimmed; an empty brand falls back to the vendor string.packagesfrom the system, one small function per half, each with a pure parser where there is text: WindowsprocessorCounts(already returns packages), macOSsysctl hw.packages, Linux the distinctphysical idvalues of/proc/cpuinfo(parsePackageCount, 0 where none is named, then 1). Where the system gives none,CpuidTopology.packagesOf(logical).std/os/tests/processor.test.trbandx86.test.trb: the composition fed with the captured dumps of #538 (one Intel, one AMD, one with and one without AVX-512) plus the three counts, including a hybrid case where the system's core count differs from the dump's topology;parsePackageCounton a one-socket, a two-socket and an Arm/proc/cpuinfo.docs/standard-library/os.mddocumentsdescribeandProcessorDescription; theskills/copy is regenerated; the "As built" note of OS.md section 7 and the slice 3 row of section 10 say what 2b did.Windows.processorTopologynative (cache data comes fromcpuidon every x86 system, so it is not needed here; step 2c decides whether Arm Windows needs it).Acceptance criteria
Processor.describe()answersOkwith a non-emptyvendorandmodel,logicalProcessors == Processor.logicalCount(),physicalCores == Processor.physicalCount(),1 <= packagesandphysicalCores <= logicalProcessors,baseFrequencyandmaximumFrequencyNone,featurescontainingSse2, and at least one cache (checked by a test that runs on the CI machines, tolerant of the machine's values).describeanswersOsError.Unsupported, as the siblings do; on a non-x86 architecture it answersUnsupporteduntil 2c (a test or thecheck --every-targetrun shows no compile error on any target).physicalCores, not the dump's, wins.parsePackageCountcounts the distinctphysical idvalues, answers 1 for a file that names none (a one-socket or Arm file) and never traps on an empty text.torb format --checkclean on touched files;sh tools/gates.sh agreen in forge CI; docs check andskills/regeneration clean.Seed impact
None expected: new std names and one new function per half; no native, no syntax change, no std name the compiler looks up by string. If CI shows otherwise, fall back to the two-commit rule.
Size
One PR, two Conventional Commits:
feat(os): processor package counts per system(the threepackagesfunctions,parsePackageCountand their tests) andfeat(os): Processor.describe and ProcessorDescription on x86-64(type, composition, tests, docs).Dependencies
Step 2a (#538) landed (
acf8510), step 1 (#488) landed. Part of #127; 2c (Arm64) and step 3 (frequencies) are not filed yet.[loop:torbscript] decided by the loop: step 2b is only
describeon x86-64 (all three systems) with the packages per system; Arm64 vendor, model, caches and features become step 2c. Why: Arm64 needs three new system sources (getauxval(AT_HWCAP),hw.optional.arm.*,IsProcessorFeaturePresent), a native or sysctl names and three per-system halves, which together withdescribewould exceed one PR of two commits (numbers: 2b touchesprocessor.trb,x86/processor.trb, three small per-system functions and their tests, about 1 h; 2c would add 3 halves and 1 to 2 natives). Also decided: caches on x86 come fromcpuidon every system, so the design'sWindows.processorTopologynative is not needed for 2b; the core count comes from the system, not fromcpuid, because a hybrid processor answers for the core it runs on (OS.md section 7, as built); non-x86 architectures answerUnsupporteduntil 2c rather than a half-filled description. Technical choices within the design record, no owner question.[loop:torbscript] claim implement by session:loop-torbscript-20261028 until 2026-10-28T20:08:15Z
[loop:torbscript] implement: PR #545 opened (#545,
Closes #543), two commits: package counts per system, thenProcessor.describeandProcessorDescriptionon x86-64 (+401/-16, 12 files). Worker hit its 30 min run limit while waiting on CI; parent verified branch pushed and clean, worktree removed. CI at handoff: commit messages, scope, pdisc, bootstrap (linux-x64) green, gates/tier A/archives/same-C/playground still pending. Worker usage: 1 run, 30 min, tokens not reported. next: waiting (CI on PR and merge gate)