>
> On 10 Mar 1997, Wayne Schlitt wrote:
> > In <m0w4Aoa-0005FcC@lightning.swansea.linux.org.uk> alan@lxorguk.ukuu.org.uk (Alan Cox) writes:
> > >
> > > > [ ... ] but that's not the point. The point is that
> > > > some of this information can be used in surprising ways and I think we
> > > > should be really careful what we allow general users to access.
> > >
> > yes, the UNIX philosophy of "everything is a file", and can be
> > protected as such, is A Good Thing. [ ... ]
>
> That'd mean to have something like msr00000000 to msrffffffff... .... ...
Or /dev/msr/nnnn a la /dev/fd/nnnn. While the address space for the
msr's is large, to the best of my knowledge, there aren't that many
that are implemented, and there probably won't be that many in the
future.
Actually, instead of using the numbers, it might be better to use
names so that two chips that have essentially the same functionality,
but in different registers can both be accessed by the same name.
(Well, I'm not sure how often that is going to be true, but it's a
thought.)
> like it's pointless to be able to set permissions for each sector on hda
> just so that a user mode program can read the partition table.
The differences is that some msr's are extremely useful to user
programs, some are useful, but must be read only, others might be
read/write.
> this is all up to the sysadmin. he's responsible.
I guess I see this as being very similar to /dev/{mem,kmem} and /proc.
Anything you can get from /proc you could get from /dev/kmem, but we
don't allow unrestricted access to /dev/{mem,kmem} because some things
in there are very sensitive.
Other versions of Unix take the approach of "let the sysadmin decide
via permissions on /dev/{mem,kmem} and set{ug}id bits", and you end up
with /bin/ps being setgid and only "special" programs can access the
information. I think the Linux approach with /proc is better.
-wayne
-- Wayne Schlitt can not assert the truth of all statements in this article and still be consistent.