wagle> I claim that /proc entries should give me EVERYTHING I *might* want
wagle> to know. Its the job of the user-land post-processor to filter and
wagle> present that information to humans, cyborgs, robots, users, and
wagle> scripts; I don't know why that intelligence should reside in a lean
wagle> mean Linux machine kernel. If I don't like your filter and/or your
wagle> presentation, I should be able to write my own without writing my
wagle> own kernel code, or writing hard-core flex/bison/etc stuff to parse
wagle> your output (ie, I'm very fond of Perl's split command).
While I agree that for programs, a non-human readable presentation with
fixed offsets is generally more parsable (perl doesn't count here :),
probably the single most useful function I've found for /proc is for
finding out what the status of your machine is when things have gone
down the tubes, often off of a root/boot floppy set. When you're dealing
with that kind of a setup, it's certainly much nicer to just use 'cat'
instead of a suite designed to parse some binary data. Perhaps make
the textual proc a compile-time option, and then add a /dev/kmem type
interface that presents a binary single-file version of the proc
interface?
-- Windows: I can play Doom! |RedHat Linux 2.0.30 i486 Linux: I can be a file server, be a Web|Because reboots are for upgrades! server, run the accounting package with|finger rasmusin@paramount.res.wpi.edu twelve terminals AND play Doom! |for pgp key. frank sweetser pgp fingerprint = 79 26 EF D7 97 EC 50 AF 17 1F 39 D9 93 6F 04 D4