From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 6 Jan 2009 12:40:15 -0500 From: Nathaniel W Filardo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20090106174015.GK8355@masters10.cs.jhu.edu> References: <1231045486.11463.245.camel@goose.sun.com> <1231130372.11463.433.camel@goose.sun.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8kI7hWEHMS8Z+7/0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [9fans] Why do we need syspipe() ? Topicbox-Message-UUID: 7ab149c6-ead4-11e9-9d60-3106f5b1d025 --8kI7hWEHMS8Z+7/0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 04, 2009 at 10:20:55PM -0800, Russ Cox wrote: > There are some devices in Plan 9 that simply don't "virtualize", > because at a deep level they are tied to process state that > doesn't go through the file system. Dup manipulates the file > descriptor table, not files themselves. Pipe accesses files that > have no name in the file system. The pid returned by getpid > needs to match the pid returned by the parent's fork; it really > needs to be the process's actual pid. For example, suppose > a process wants to know . If getpid read from /dev/pid > instead of #c/pid, then running "iostats rc -c 'echo $pid'" > would show iostats's pid, not rc's. What then if rc wants to send > itself (or, more likely, its note group) a note, or fiddle with > one of its /proc files? It would be manipulating iostats, not > itself. > >[snip #s #a and #D] This just means that these services need to be mounted at the canonical place in the namepsace atop the root provided by iostats. That yields equivalent behavior -- the kernel sees the right process making the call and iostats sees nothing at all -- but it is, I agree, unsatisfactory. --nwf; --8kI7hWEHMS8Z+7/0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkljl38ACgkQTeQabvr9Tc/EKgCZAf1VB6by8P65OsFyvWLljTkh kMoAniqDclYD838HbGxB/7EEGOs3uxG5 =Kh1x -----END PGP SIGNATURE----- --8kI7hWEHMS8Z+7/0--