Re: Reflection and /proc

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

Albert D. Cahalan wrote:
> 
> Davide Bolcioni writes:
> 
> > - content would vary from /proc/$$/stat, parsable with scanf(), to
> > /proc/$$/status, which has some human-readable English spread over
> > multiple lines;
> ...
> > 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 ?
> 
> I am one of the procps hackers. I recently rewrote large parts
> of the collection, including all of "ps" and "skill".
> 
> The /proc/$$/stat file format is OK. (binary is better)
> The worst problem I have seen was signal info in hex.
> I think hex is great, but one can't just switch to it.
Embracing the /proc/$$/stat format, the files would still be easy to
parse with many scripting languages and traditional Unix tools. It is
also size-independent (when something moves to 64 bits, you get a bigger
number). It might also reduce the amount of sprintf()-like formatting in
the kernel, although not by much I suspect.

> The /proc/$$/status file format is bad. Besides being slow,
> it is unreliable. People are tempted to change the spelling!
> I had to send in a patch to revert some 2.1.xx changes.
This puts the finger on the source of my doubts about /proc: it is easy
to get in a situation where what the kernel puts there is not what user
code expects to. Even if it is decided that only "special" applications
like ps(1) and libraries should access /proc (which is not the current
practice, it seems to me), if and when this happens, the damage is
system-wide. With system calls, you (meaning you, procps developer)
would have .h files. Of course, system calls would have other problems.

> My ideal format would be an array of 64-bit values.
> Data that takes a long time to collect should be separate.
You're referring to "summary" data which requires walking kernel
structures, I assume.

> Data should also be grouped by security requirements.
This is in order to use filesystem protection to control access, I
guess.

> The latest procps code:
> http://www.cs.uml.edu/~acahalan/linux/procps-990224.tar.gz
> -
> 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