Path: utzoo!attcan!uunet!cs.utexas.edu!jsq
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-ID: <14134@cs.utexas.edu>
Date: 30 Oct 90 06:37:16 GMT
References: <13878@cs.utexas.edu> <14014@cs.utexas.edu> <14101@cs.utexas.edu> <14110@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 27
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jfh@rpp386.cactus.org (John F. Haugh II)

In article <14110@cs.utexas.edu> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>That's the most common implementation.  However, /dev/fd could also be
>implemented as a filesystem type of its own, and I'd actually prefer
>that.  Then an "ls /dev/fd" would show just the in-use file descriptors.

Which brings up the issue of "whose in-use file descriptors?".
It would work just fine for the application itself, but "ls" would
be useless if you define "in-use" to be the current process' in-use
descriptors.  Gee, how many times do you want to see which file
descriptors "ls" has open.

This works with /proc because processes are system wide, while file
descriptors are per-process.  My fd0 has nothing in common with your
fd0 - so either I distinguish between my fd0 and your fd0 and get
stuck with fondling every user-page in the system, or I just cop out.

A more complex inplementation buys little or nothing in terms of
function at a very high cost in terms of overhead.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson

Volume-Number: Volume 22, Number 10