Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!usc!apple!mips!zorba!dtynan
From: guy@auspex (Guy Harris)
Newsgroups: comp.unix
Subject: Re: An idea probably discarded many times
Message-ID: <3529@zorba.Tynan.COM>
Date: 4 Jan 90 06:59:13 GMT
References: <3481@zorba.Tynan.COM> <3495@zorba.Tynan.COM> <3520@zorba.Tynan.COM>
Sender: dtynan@zorba.Tynan.COM
Reply-To: uunet!auspex!guy (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 22
Approved: dtynan@zorba.Tynan.COM

>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.