Reflection and /proc

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

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.
  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.

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.

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 ?

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 ?

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