Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!usc!apple!zorba!dtynan From: rubin@cbnewsl.ATT.COM (michael.rubin) Newsgroups: comp.unix Subject: Re: An idea probably discarded many times Message-ID: <3519@zorba.Tynan.COM> Date: 26 Nov 89 20:05:09 GMT References: <3481@zorba.Tynan.COM> Sender: dtynan@zorba.Tynan.COM Reply-To: rubin@cbnewsl.ATT.COM (Mike Rubin) Organization: AT&T Bell Laboratories Lines: 27 Approved: dtynan@zorba.Tynan.COM In article <3481@zorba.Tynan.COM> r_gonzalez@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