r_gonzalez@unhh.bitnet (Roger Gonzalez ) (10/08/89)
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. Doing a 'ls -l' might reveal something like: total 5 prwxrwx--- 1 rg 581 Sep 18 13:36 a.out* prwxrw-rw- 1 daemon 4736 Sep 5 16:56 huntd* prwx------ 1 root 2293 Sep 18 13:37 who* etc. 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. We did this mainly to simplify porting standard code to our wierd environment. The system works well enough for us that I was curious why Unix wasn't implemented with processes in the file system as well. -Roger ------------------------- Roger Gonzalez Marine Systems Engineering Laboratory University of New Hampshire unhd!rg@cs.utexas.edu r_gonzalez@unhh.bitnet
gak@sun.com (Richard Stueven) (10/15/89)
>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 While I was with AT&T, we heard lots of rumors from Bell Labs about this feature being incorporated into SVR4. I should stress that they're just rumors, as I never saw any formal requirements or anything like that...but I'm keeping my eyes open! And I agree with you...it will be a nice addition. have fun gak -- Richard Stueven gak@sun.com ...!attmail!rstueven ***These opinions belong to Ernie and his little pal Gus.*** ***He's mad! Mad, I tell you!***
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (10/15/89)
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... This is in SVR4. On this machine (running a preliminary version of the code on SVR3) the file system is called /proc. File names in /proc are process numbers. $ ls -l /proc total 25746 -rw------- 1 root root 6144 Oct 9 09:05 00000 -rw------- 1 root root 61440 Oct 9 09:05 00001 -rw------- 1 root root 0 Oct 9 09:05 00002 -rw------- 1 root root 0 Oct 9 09:05 00003 -rw------- 1 root root 83968 Oct 9 09:05 00144 ---------- 1 root root 18432 Oct 9 09:05 00164 -rw------- 1 lvc user 131072 Oct 9 09:05 13531 ... >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. All the typical message passing schemes are still in SVR4. /proc files can be opened and ioctl's applied to them for process control/debugging purposes. The pi debugger by Tom Cargill does exactly this. Another benefit of putting process images in the file system is that /proc is "just another file system" and can be mounted on a remote system with RFS so you can debug programs on remote machines. Neat eh? -- Larry Cipriani, att!cbsck!larry or larry@cbsck.att.com
larry@macom1.UUCP (Larry Taborek) (10/15/89)
> 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. Doing a 'ls -l' might reveal something like: > > total 5 > prwxrwx--- 1 rg 581 Sep 18 13:36 a.out* > prwxrw-rw- 1 daemon 4736 Sep 5 16:56 huntd* > prwx------ 1 root 2293 Sep 18 13:37 who* > etc. > > -Roger I'm no wizard Roger but it seems to me that updating the process table in memory would be alot faster then the system calls needed to create an entry in the file system and directory needed only to post some inode information that is already available in the process tables. (whew!) ie, your imposing alot of overhead for nothing. Processes in Unix are alot like files though, they have user and group permissions just like files. Hope this helps...
johnl@esegue.segue.boston.ma.us (John R. Levine) (10/27/89)
In article <3495@zorba.Tynan.COM> larry@macom1.UUCP (Larry Taborek) writes: >> I think it would be a nice addition to Unix to have a virtual >> '/proc' directory mounted in the file system. ... >I'm no wizard Roger but it seems to me that updating the process table in >memory would be a lot faster than the system calls needed to create an entry >in the file system and directory needed only to post some inode information >that is already available in the process tables. (whew!) [spelling corrected] Who said anything about creating file system entries? In implementations of /proc that I've heard of, it's a virtual rather than real file system, which means that its contents are created on the fly when somebody opens and reads or writes one of the files in it. If nobody's looking in /proc, there's no work to do. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
tchrist@convex.COM (Tom Christiansen) (10/27/89)
In article <3495@zorba.Tynan.COM> larry@macom1.UUCP (Larry Taborek) writes: >Processes in Unix are alot like files though, they have user and >group permissions just like files. untrue. process groups are more analogous to directory sub-trees than to group id's. --tom Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
rubin@cbnewsl.ATT.COM (michael.rubin) (11/27/89)
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 <mike@sfbat.att.com>
karl@MorningStar.Com (Karl Fox) (11/27/89)
In article <3495@zorba.Tynan.COM> larry@macom1.UUCP (Larry Taborek) writes: > 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. I'm no wizard Roger but it seems to me that updating the process table in memory would be alot faster then the system calls needed to create an entry in the file system and directory needed only to post some inode information that is already available in the process tables. (whew!) ie, your imposing alot of overhead for nothing. It doesn't have to work this way. Nothing needs to work differently until the ``ls /proc'' does a read() from the special /proc directory (is it even a directory?). The read() system call could then switch out to code that examines the proc table and feeds appropriate bytes back to the caller. -- Karl Fox, Morning Star Technologies karl@MorningStar.COM No disclaimer needed -- RTFM for Usenet.
mayoff@walt.cc.utexas.edu (Rob Mayoff) (11/27/89)
In article <3508@zorba.Tynan.COM> uunet!convex.COM!tchrist (Tom Christiansen) writes: >In article <3495@zorba.Tynan.COM> larry@macom1.UUCP (Larry Taborek) writes: >>Processes in Unix are alot like files though, they have user and >>group permissions just like files. > >untrue. process groups are more analogous to directory sub-trees than >to group id's. <.sig deleted> Actually, process groups aren't much like directory trees either. There are, IMHO, THREE important numbers associated with a process that have to do with permissions: real UID, effective UID, and process group number. The real & effective UID's lead to the GIDs. Processes don't have the rwx type permissions. The UIDs and the GIDs related to them determine what files are accessible by the process, and the process group number determines whether the process can write to certain terminals (so long as you are using the new terminal driver, which you are if you use csh w/ job control). I'd suggest that for a virtual /proc implementation, the UID should be the process's effective UID, the GID be something like wheel or bin or maybe some new group devoted to owning processes, and that process files have two more qualities associated with them: controlling terminal and process group (similar to major/minor device numbers). Actually, other values could also be associated - resource usages (similar to file size) and the pathname of the executable file which this process is an instance of. rob "This is vi? So when does version vii come out?"
cudcv@cu.warwick.ac.uk (Rob McMahon) (11/27/89)
In article <3508@zorba.Tynan.COM> uunet!convex.COM!tchrist (Tom Christiansen) writes: >In article <3495@zorba.Tynan.COM> larry@macom1.UUCP (Larry Taborek) writes: >>Processes in Unix are alot like files though, they have user and >>group permissions just like files. > >untrue. process groups are more analogous to directory sub-trees than >to group id's. I'm not completely convinced by this, processes have a very obvious parent/ child/sibling relationship, and presumably Larry was talking about the effective (or real ?) group id of the process, rather than it's process group. It does bring up an interesting point about /proc, though: what does the directory structure look like ? It would seem to be logical and useful to have it organised as a tree, with childless processes appearing as files, and those with children appearing as directories, with their children as entries. It might require you to be able to open a `directory' for writing, is this a per-filesystem attribute, or would this cause any problems ? Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
guy@auspex (Guy Harris) (01/04/90)
>It doesn't have to work this way. Nothing needs to work differently until >the ``ls /proc'' does a read() from the special /proc directory (is it even >a directory?). Yes, it is a directory. >The read() system call could then switch out to code that >examines the proc table and feeds appropriate bytes back to the caller. Actually, in S5R4 at least, 1) "/proc" is a VFS under the S5R4 Virtual File System mechanism (similar to the SunOS 4.x one, but with assorted improvements), so the "read" call doesn't know about it, it just calls the appropriate "read" operator for the "/proc" VFS, just as it would for the S5 file system or the BSD file system or NFS or RFS or.... (i.e., you don't have to teach it specially about "/proc") 2) "ls" would be using the "getdents()" call, not "read()", and go to the "read directory" VFS operation, not the "read" operation.
guy@auspex (Guy Harris) (01/04/90)
>It does bring up an interesting point about /proc, though: what does the >directory structure look like ? It's a flat directory with one entry per process on the system; the file name being an ASCII version of the process ID.