Re: procfs problems

Evan Jeffrey (ejeffrey@eliot82.wustl.edu)
Wed, 16 Apr 1997 18:55:12 -0500


Stefan Monnier said:
>
>Evan Jeffrey <ejeffrey@eliot82.wustl.edu> writes:
>> > /proc -> /system/proc
>> > /dev/fd -> /system/fd
>> > /dev/scd0 -> /system/devices/scsi0/target6/lun0
>> People are going to scream bloody murder about that. It breaks a lot of
>> stuff. OTOH, whatever we do to /proc is going to break some stuff.
>
>Apart from the /proc/<nonsense> files, it doesn't break anything.
>And below, you claim that they are for human consumption, so it doesn't
>matter too much if you move them (it breaks humans, but that's OK).

Actually, I think that the structure proposed is the Right Thing, I was just
pointing out that it was going to break a lot of things (quite a lot,
actually) though grep should be able to find most of the places that need to
be changed.

>I admit that I love command-lines, but do you really believe that the
>text-output of /proc files corresponds to current computer systems with
>1600x1200x16bits screens (as far as I'm concerned) and current computer users
>who like Netscape more than trn to read their news ?

sscanf isn't that hard to use if you know the format (I *DO* advocate a
standard text format, of some sort)

There is a lot of information in /proc. No matter how much we standardize,
there are many fundamentally different types of information, which should be
treated differently.

If people don't like parsing text, isn't that what sysctl is for?

Besides, do people who can't use command lines care which device has which
IRQ, or what the stepping on the CPU is?

>What is the complication of mixing text and binary ? Where did you see that
>text and binary should be mixed in the /system/info files ?

Strings are necissary, both for field labels (which could be standardized)
and for some of the actual information. Trying to use fixed length stings
is bad both asthetically and practically. It imposes unnecissary limits,
and some of the strings are very long--try looking at the cmdline entry for
something like:
grep OBSCURE_KERNEL_DEFINE `find -name "*.[c,h]"`
On the other hand, variable lenght strings bring back the original problem:
you still have to find out how long the string is and skip over it to get to
the next datum. At which point I don't think you have saved any effort.

Evan Jeffrey
ejeffrey@eliot82.wustl.edu