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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
