Mike Meyer wrote:
On Sun, 18 May 2008 16:50:28 +0100
Rui Paulo <[EMAIL PROTECTED]> wrote:
Mike Meyer wrote:
On Sat, 17 May 2008 11:13:52 +0300
Andriy Gapon <[EMAIL PROTECTED]> wrote:
It seems that rdmsr instruction can be executed only at the highest
privilege level and thus is not permitted from userland. Maybe we should
provide something like Linux /dev/cpu/msr?
I don't like interface of that device, I think that ioctl approach would
be preferable in this case.
Something like create /dev/cpuN and allow some ioctls on it:
ioctl(cpu_fd, CPU_RDMSR, arg).
What do you think?
Ok, this points directly at a question I've been wondering about, but
haven't been able to find an answer in the google.
I've been mucking about with general access to sysctl's (a sysctl
plugin for gkrellm, and a python module for accessing sysctls), and
with that hammer in my hand, the nail for this problem is obviously a
dev.cpu.#.msr sysctl.
How can you request a rdmsr within the sysctl tree? I don't think sysctl
is appropriate here either.
Reading (or writing) a sysctl mib can trigger a sysctl handler, which
can do pretty much anything. In particular, there are already examples
in the kernel where sysctl handlers use devices that don't have /dev
entries to get & set their values. Look through kern/kern_cpu.c and
i386/cpufreq/p4tcc.c to see the two ends of that kind of
connection. In fact, the cpu frequency sysctls would seem to be an
excellent model for something like the msr.
ioctl, open+read/write, sysctl - they're all just interfaces to kernel
handlers.
<mike
Yes, sure, but who do you select the MSR you want to read or write?
dev.cpu.N.<insert MSR number in hexadecimal here> ?
I'll have to think about whether or not I like this interface.
Regards,
--
Rui Paulo
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
