Messages in this thread | | | Date | Tue, 15 Apr 1997 13:41:33 -0700 (PDT) | From | Dan Hollis <> | Subject | Re: procfs problems |
| |
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.
-Dan
| |