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
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
