Re: proc fs and shared pids

Marek Michalkiewicz (
Fri, 9 Aug 1996 01:28:05 +0200 (MET DST)

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).