Messages in this thread |  | | | From | Stefan Monnier <monnier+/news/lists/linux/> | | Subject | Re: procfs problems | | Date | 15 Apr 1997 19:45:57 -0400 |
| |
Dan Hollis <goemon@sasami.anime.net> writes: > Those of you interested in discussing design flaws with the current procfs [...] > I invite comments.
Linux's procfs is just one big mess. My question is (as a newcomer): why did people even start putting things in /proc other than process info ?
If someone wants to "restructure" procfs, wouldn't it make more sense to turn it into "kernelfs" or "systemfs" (typically mounted on /system) and have
/proc -> /system/proc /dev/fd -> /system/fd /dev/scd0 -> /system/devices/scsi0/target6/lun0
(that last one assumes that something similar to Solaris' /devices gets developped. Of course one would also have various info available under /system/info/cpu (doesn't sound more natural than /proc/cpuinfo))
As a "strong typing" bigot, it just seems wrong that /proc/* doesn't just match processes but also random info about my kernel state, devices attached, ... Of course, I'd also love to see the /system/info directory be organised. Ideally, the content of each and every file would be in a standard (and binary, but I'm sure string-lovers will jump at me right here) format with library functions to turn those binary streams into strings (and a corresponding bin2text programs for those who want to replace "cat /proc/cpuinfo" by "bin2text /system/info/cpu"). That standard format would be probably some kind of associative table (hash/splay tree/alist/whatever) and every entry would have some info indicating whether it holds a string, a integer, a float or a sub-table (indexed by strings or by integers).
Stefan
|  |