Re: Reflection and /proc

[Davide Bolcioni <davide.bolcioni@3di.it>]

Dominik Kubla wrote:
> 
> 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).
I beg your pardon ? What field of struct rusage are you referring to ?
 
> >   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.
Yes, I was not discussing or advocating granularity (I am not a fan of
ACLs); I was just investigating this "filesystem view", whatever the
security. Also, no criticism is implied; in fact, I am not sure that
such a reflection API is ever necessary. The problem with read() to get
information from /proc is that some files are easily parsed, even with
scanf(), some require a bit more work; an API would document the format
as a struct in a header file, while the file format is in a man page
which just seems easier to get out of sync.

> > 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).
That was in glibc last time I looked; I am not saying parsing /etc/mtab
or its cousin /proc/mounts is a bad idea.
 
> > 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!
A penchant for reinventing the wheel is a trademark of the Unix
attitude, it seems to me, and for once I agree with Mr. Calahan: the
mainstream will follow. Yet, that was not my point: what is the right
tool for the job at the kernel system call interface, and how does this
reflect on the kind of programs which get written ?

If everything is to be read from /proc:
- protection, as you suggested, would be ordinary filesystem fare;
- content would vary from /proc/$$/stat, parsable with scanf(), to
/proc/$$/status, which has some human-readable English spread over
multiple lines;
- content would be documented in man pages or, possibly, in the kernel
source;
- programmers (library programmers first) would consider this a "slow"
interface, perhaps incorrectly, and would try to write wrappers which
attempt to cache information instead of going through open(), read(),
scanf(), close() on each request;
- programs which modify would read what they need, store it in a form
appropriate for update, consider it, make the modification and update
the stored form accordingly.

If there is a set of "reflection" system calls:
- a protection mechanism will be probably be needed (maybe something
like device
nodes would enable reuse of filesystem protection);
- content would be C structures, I suppose;
- content would be documented in Linux-specific header files;
- the /proc interface would be a duplicate providing the same
information to scripts, like sysctl() but read-only;
- same programmers would consider this a "fast" interface (after all,
even if system calls are slow, one is performed instead of three ...
although a cache of open /proc files might help) and write wrappers
which just perform the system call;
- programs which modify would read what they need, consider it and make
the modification, without updating because reading it back will be
"cheap".

Now, it seems that "reflection" calls would yield more performance in
getting, for example, the fsuid/fsgid of a process; yet I suspect that
the other approach may lead to better performing programs, just as the
mantra "system calls are expensive" led to all kinds of clever
optimizations. This is also an argument in favor of the "no reflection"
option: even system calls might not be performance enough.

> > 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.
The bad solution is nationalized /proc, I gather, so I guess /proc is
intended for scripts and possibly for C programs: /proc/$$/stat is
"right" (scanf one-liner), while /proc/$$/status less so (multi-line
with English). Is this what you mean ?
 
> 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

Davide Bolcioni
-- 
#include <disclaimer.h> // Standard disclaimer applies
-
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