If you look at my patch you'll notice threre are two interfaces: the
ASCII one which is for the system administrator and the ioctl() one
which is meant for programmers. I don't have a problem with changes to
the ASCII interface, since programmes should not rely on it: they
should use the ioctl() interface.
The ASCII read interface is important so the sysadmin can see what's
going on without requiring special tools.
I had originally looked at using sysctl() but it looks like that is
more tuned to setting kernel parameters in memory tables.
> Consider the inefficiency of /proc. I understant that setting MTRR
> registers is done once in a blue moon - however its the principle that
> counts. As it stands right now, far too many utilities/programs rely on
> /proc. Look at "top": 2-8% CPU to display 70 mostly sleeping processes!
> At the risk of repeating myself - an HPUX top manages to fit into 2%
> with 400 processes - worse yet, on a slower CPU. Thats shameful - where
> has the concent of efficiency gone?
I agree that there should be an alternative way of accessing the /proc
information: reading and decoding ASCII is a loose. That's what sysctl
is for, in general.
I believe more /proc entries should provide ioctl() interfaces for the
benefit of C programmes.
I've also made the kernel-side computation of the ASCII information
done when the MTRRs are changed, not every time you read /proc/mtrr. I
can get away with this because the amount of information in there is
trivial. It also has the advantage of allowing me to set the size of
the file, so you can use less and friends. Something no other /proc
entry does, I believe :-)
> As a final argument I'd like to present the possibility that not
> everyone will enable /proc when running Linux.
IMHO /proc is so essential that virtually everybody uses it. It's a
must for sysadmin.
> P.S. Sorry for the long-winded monologue but this is a pet pieve of mine. :)
;-)
Regards,
Richard....