Messages in this thread | | | Date | Wed, 30 Apr 1997 17:37:29 -0400 | From | Frank Sweetser <> | Subject | Re: procfs problems |
| |
==> Regarding Re: procfs problems; Perry Wagle <wagle@tuple.cse.ogi.edu> adds:
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
| |