[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reflection and /proc
On Mon, Mar 01, 1999 at 09:51:40AM +0100, Davide Bolcioni wrote:
> I harbor the impression that the Linux/Unix system call API provides an
> adequate "set" interface but not the corresponding "get" interface: for
> example, how do I get the number of files currently open in my process ?
> One way could be to loop from 0 to getdtablesize() - 1 and
> fcntl(F_GETFL), counting successes. Well, not much of an example.
Right, because the correct answer to your question is getrusage(2).
> The /proc interface typically allows much broader inspection of the
> state of the machine, but requires read() and some parsing. It also does
> take some performance penalty, I suppose. I remember a thread on the
> kernel list discussing the intent of the proc interface, but not if an
> answer came up:
> - is /proc for human users (it should be nationalized then) ?
> - is /proc for scripts (english only, should be easy to parse) ?
> - is /proc for C programs (why not binary data then) ?
> - is /proc a compromise of the last two ?
> Note: I am not considering security. Other reflection APIs typically
> offer more granular protection than /dev/kmem.
/proc is intended to offer a "file system view" of the kernel space
exactely so that one could use read(2) to get what one wanted. There is
nothing else it should do. So your criticism doesn't hold: it was designed
that way. As for more security granulation: ASA Linux has file system ACL's
(which were discussed here at lenght) the proc-fs will have all the
granularity you want.
> A better example: mounted filesystems. Traditional Unix had /etc/mtab,
> and the attitude wrt "reflection" (investigation of the state of the
> system) was that it is more or less unnecessary: the tool performing
> "set" records the state in ordinary files. Still read() and parse.
Wrong answer: getmntent(2).
> So there are really two questions:
> - what is better, have concerned tools obtain system state information
> through slow/cumbersome channels (slow/cumbersome enough that the
> average programmer organizes his code to read it once at startup and
> track it thereafter) or provide a more comprehensive reflection API (so
> that same programmer just calls for the information when he needs it,
> merrily paying the cost of a system call) ?
> - if a reflection API is provided, what is /proc going to be ?
I think i already answered Q2. The answer to Q1 however is RTFM and in a
corollary to that "read the fucking standards". The Linux community has the
somewhat disturbing habit of reinventing the wheel just to be different.
This is no longer going to work: we have hit the mainstream folks!
> Implementation note:
> - if /proc were to be nationalized, how could it be implemented ?
> Duplicate NLS support in the kernel or remove /proc to a userspace
> daemon so it can use NLS in glibc ?
NLS in kernel space is a no-no. We had this discussion over and over again.
A user-space daemon OTOH is possible but will need kernel support, like
IBM's message codes, and there you go again... Who will run the registry
for those codes?
IMHO it is reasonable to expect from a sysadmin to be able to at least
lookup the meaning of a system message in a native language manual or even
comprehend it without this.
All that talk about NLS and kernel is IMHO trying to find a problem for a
(bad) solution.
Yours,
Dominik Kubla
-
Linux-future: thinking about the future of the Linux kernel
Archive: http://humbolt.nl.linux.org/lists/
Wish list: http://users.ox.ac.uk/~mert0236/linux-future.html