rdmsr from userspace

[Rui Paulo]

Mike Meyer wrote:
> 
> I don't think that would work - you'd have to register all those
> hexadecimal strings as sysctl names.

Yes, in theory you could also hack sysctl in a way that it doesn't walk 
when you do a sysctl -a, but works fine when you issue sysctl 
dev.cpu.N.0xffaabbcc, for example.
I would be against this, though, because this will be like "sysctl on 
steroids", a really crude hack.

> You could do an interface like
> this, but the calling program would have to use sysctlnametomib to get
> dev.cpu.N.msr, then append the MSR number to the results. Not really
> very pretty.  If you want to allow the user to poke at arbitrary msrs,
> this would be a way to do it with sysctls, but the file api is
> probably better.

Agreed.

> On the other hand, if you want to allow access to the fixed set of
> documented msr's (for each cpu model, anyway), then handing back that
> fixed set as an array would be a better approach, and would have the
> advantage of not having to deal with invalid requests (non-existent
> MSRs, 1-byte reads/writes of multi-byte MSRs, etc).
> 
> On the other hand, it might be more useful - *especially* if the MSRs
> move around depending on processor types (I honestly don't know)

They do. At least on Intel (I don't know about AMD). But this "moving" 
is not documented.

> - to
> provide a "named" interface:
> 
>      dev.cpu.0.msr.mtrr
>      dev.cpu.0.msr.arr
>      dev.cpu.0.msr.efer
> 
> and so on. You'd register the names when the module was initialized,
> and would only register the ones that actually existed. You'd then
> never have to deal with a request for a non-existent MSR, because the
> sysctl call would return an error to the calling program without ever
> calling your handler.
> 
> Of course, you can *combine* these two approaches, and have:
> 
>    dev.cpu.0.msr.all		# returns an array of all available msrs
>    dev.cpu.0.msr.have		# an array of the available msrs
> 
> but at this point it's just blue sky speculation...
> 
>> I'll have to think about whether or not I like this interface.
> 
> Actually, I'm more interested in why there seems to be a dislike
> of file-based interfaces in favor of sysctls in the freebsd
> community.

Speaking for myself, sometimes sysctl is an interface that "just works" 
and is simple enough. Of course there are some types of structured data 
that don't belong to sysctl, but overall, I don't think we are abusing it.
Creating a /dev node, handling ioctl's, etc. is much more work and error 
prone. That's all. At least for me.

Regards,
-- 
Rui Paulo