Re: [PATCH v2 1/2] x86/msr: Document I/O-like MSR semantics in /dev/cpu/*/msr driver
From: Tim Wiederhake
Date: Mon Jun 29 2026 - 11:20:39 EST
On Fri, 2026-06-26 at 14:42 -0700, H. Peter Anvin wrote:
> On 2026-06-26 13:33, Tim Wiederhake wrote:
> >
> > This version splits the change in two:
> >
> > 1/2 adds a comment explaining why the driver loops over the same
> > register, so future readers don't have to rediscover the
> > rationale.
> > 2/2 removes only the read loop, where repeated access to the same
> > register is less obviously useful.
> >
> The same applies to the read loop, although the use case(s) are
> obviously
> different.
>
> Either way, you risk breaking working tools for no reason.
>
> -hpa
While looking into this I also noticed that /dev/cpu/*/msr is the only
register-addressed character device that doesn't advance ppos on read.
/dev/cpu/*/cpuid, /dev/port, and /dev/nvram do. That causes ftell() and
lseek(SEEK_CUR, 0) to disagree after an fread(). I don't know how
important that is though, and whether that is more of a glibc issue.
Can you please point me to a tool that uses the multiple-read behavior?
I want to mention that in the file comment, but turbostat, rdmsr,
cpupower, coreboot's inteltool, all read exactly 8 bytes.
Thanks for the review,
Tim