Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 May 2008 13:32:28 -0400
From:      Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org>
To:        Rui Paulo <rpaulo@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, Andriy Gapon <avg@icyb.net.ua>
Subject:   Re: rdmsr from userspace
Message-ID:  <20080517133228.02c9ea5c@bhuda.mired.org>
In-Reply-To: <482F1529.5080409@FreeBSD.org>
References:  <482E93C0.4070802@icyb.net.ua> <482EFBA0.30107@FreeBSD.org> <482F1191.70709@icyb.net.ua> <482F1529.5080409@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 May 2008 18:26:01 +0100
Rui Paulo <rpaulo@FreeBSD.org> wrote:

> Andriy Gapon wrote:
> > on 17/05/2008 18:37 Rui Paulo said the following:
> >> Andriy Gapon 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?
> >>>
> >>
> >> While I think this (devcpu) is good for testing and development, I 
> >> prefer having a device driver to handle that specific MSR than a 
> >> generic /dev/cpuN where you can issue MSRs.
> >> Both for security and reliability reasons.
> > 
> > What about /dev/pci, /dev/io? Aren't they a precedent?
> 
> They are, but, IMHO, we should no longer continue to create this type of 
> interfaces.

Ok, in relation to the question I asked about sysctl's vs. /dev/* -
why not?

    <mike
-- 
Mike Meyer <mwm@mired.org>		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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080517133228.02c9ea5c>