lkml.org 
[lkml]   [1997]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.314 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site