Messages in this thread |  | | From | Marek Michalkiewicz <> | Subject | Re: proc fs and shared pids | Date | 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).
Marek
|  |