Re: procfs problems

Pat Caldon (patc@felix.antiquity.arts.su.edu.au)
Fri, 18 Apr 1997 00:54:47 +1000 (EST)


>
> Baldur Norddahl <bbn@dark.x.dtu.dk> writes:
> > I could spawn the 'bin2text' program but then perfomance is going to
> > suck. If I don't want to spawn bin2text I need to store translation tables
> > inside my program, and thereby incresse the changes that my program wont
>
> Did you actually read my post ?
> I said there would be a library to read those files and bin2text would just be
> a front end to that library for those who insist on using fork/exec.
>

This is possibly not a good idea. A few times /proc has saved me from a lot
of hassle in a system which wouldn't get out of single user mode; once it
helped me diagnose a "dynamic libraries won't load" style problem. Much
of its value is in being a human readable thing when everything else is
screwing up, all that's needed is a statically linked bash, ls and cat
and you can disgnose most problems.

The other thing I note is that the proposed /proc standards have been
focusing heavily on /proc/cpuinfo, but not caring about the actually
useful things like /proc/filesystems and /proc/mounts (these along with
/proc/pci being the aforementioned butt-savers). These do not have simple
"key :: value"" style data in them; they're close to being arrays, or
complex type data.

Stupid idea #1476 : why not make the data parsable by something like perl
or python as source code? /proc/filesystems becomes:
$fs[1] = "ext2";
$fs[2] = "minix";
$fs[3] = "nfs";
&c.
This makes it trivial to make comments like "The Linux kernel uses the
Internet Compatible programming language Perl as one of its primary
interfaces, making it easier to implement Internet-and-Intranet ready
toold for Systems Management" in Press Releases which would perhaps impress
journalistic types.

pat.