An idea probably discarded many times

[michael.rubin]

In article <3481 at zorba.Tynan.COM> r_gonzalez at unhh.bitnet (Roger Gonzalez ) writes:
>Since one of Unix's claims to fame is the fact that "everything is a file",
>why aren't processes treated the same way?  I think it would be a nice
>addition to Unix to have a virtual '/proc' directory mounted in the file
>system.
(...)
>And instead of the typical message passing scheme(s), pipes, and what-not,
>all processes have "buffer areas" which they can use or choose to ignore,
>and you can open a process just as if it were a file.  I have worked on
>a similar idea (although on a real-time multi-cpu OS where we don't have a
>file system at all) where all process<->process and process<->device I/O looks
>for all the world like your standard open, close, read, write, and ioctl
>calls.

System V release 4 will indeed have a /proc filesystem; if you look in /proc
it contains one file per running process, the filename is the process ID,
and the file size is the size of the process's core image.
It's like having a /dev/kmem for each process rather than just the kernel.
The only current use of /proc is for debuggers and program tracers.

Reads and writes to a file in /proc would actually be touching the text or
data of the running process (not much use except as a new way of writing
self-modifying code :-).  The problem with using /proc for interprocess
communication is that each process would have only one input channel,
rather than being able to open many sockets for reading from different sources.

--Mike Rubin <mike at sfbat.att.com>