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

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site