[lkml]   [1996]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: proc fs and shared pids
    Michiel Boland:
    > I personally think /proc/<pid> in its present state is just
    > about useless, since one has to do an awful lot of reading,
    > parsing etc. to get the process status.

    Yes, it's slow... Also, lots of unrelated things (not just
    processes) are all in /proc, not just processes.

    > A solaris-like implementation of /proc would be handy.
    > (Sound of breaking programs in the background)

    I think it is possible to do this without breaking existing
    programs, we just have to mount the new filesystem somewhere
    else than /proc. It is unfortunate that originally the name
    /proc was chosen for something different than /proc on other
    systems - we might have a problem if SVR4 /proc ever becomes
    part of some standard (POSIX, X/Open, whatever), and we
    probably want to follow standards...

    Some things could be done cleaner in device drivers, no need
    to store the directory tree structure in the kernel - just
    create special files with the right major/minor numbers.
    For example, we might have a /dev/fd/* driver - one major,
    256 minor devices for 256 file descriptors (I know we want
    to remove that arbitrary limit, but then we plan to move to
    a 32-bit dev_t as well, problem solved). If we know that
    /dev/fd/* is always available (the symlink to /proc/self/fd
    only works if /proc is mounted), we could use that for safe
    setuid scripts, for example (pass /dev/fd/n instead of the
    script name to the interpreter, avoiding a race condition).


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