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