Re: procfs problems

Dan Hollis (
Tue, 15 Apr 1997 13:41:33 -0700 (PDT)

On Tue, 15 Apr 1997, Philip Blundell wrote:
> On Tue, 15 Apr 1997, Dan Hollis wrote:
> > It should be standardized. Right now there's *no* standardization in the
> > kernel, which makes parsing the information the biggest pain in the ass.
> > Having to write 5 different parsers for the same information is *not* the
> > way to go.
> Fix it and make a patch then. I'm sure nobody would object to it being
> tidied up. Ditto your "multiple devices" complaint, though I have a
> feeling that might be a bit less widely accepted.

Why? It's The Right Way(tm). Someone just emailed me about possibly doing
a Linux port to a 1024 CPU MIPS system. Imagine what a monster
/proc/cpuinfo is going to be to parse, especially if you want info on just
a single CPU out of the 1024. Even /proc/cpu/x is less than perfect in
such a situation, but it Sucks Less(tm) than one giant /proc/cpuinfo.

> The bit about "design inconsistency" on your page is just garbage as far
> as I can tell. The reason there is no /proc/ide is because nobody felt it
> would be useful enough to bother writing one. Its absence doesn't in any
> way invalidate /proc/scsi's presence, nor vice versa. Yet again, if you
> think it would be that much of an improvement to the world, why not
> implement it and send us your patch?

Instead of haphazardly cocking up a patch in 10 minutes, I want to make
sure of doing it The Right Way, The First Time(tm). That's why I'm opening
this to discussion to make sure I haven't missed anything. Perhaps someone
can shed light on A Better Way(tm).

I've received a lot of positive comments in email, so I think i'll start
on a new procfs proposal. I want to get the overall design approved before
I start cranking out patches.