lkml.org 
[lkml]   [1996]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: proc fs and shared pids
Date
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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.028 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site