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


     \ /
      Last update: 2005-03-22 13:39    [W:0.019 / U:0.828 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site