Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!usenix!jsq
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <557@usenix.ORG>
Date: 28 Sep 90 16:00:33 GMT
References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 27
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <540@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>You must convince us that open() makes sense for everything that might
>be a file descriptor, ...

open() provides a mechanism for obtaining the object's handle ("file
descriptor") in the first place.  The argument is really about whether
there ought to be more than one way to originate such a handle.  (dup(),
fork(), etc. merely propagate a handle obtained by other means.)  It is
possible, as I described over a year ago in the now-defunct
comp.unix.wizards newsgroup, to design a UNIX-like operating system
where "it takes a handle to get a handle".  However, UNIX is definitely
not like that.  From a software engineering viewpoint, if a single
mechanism for originating handles will suffice, then that is the best
approach.

The hierarchical filesystem serves a useful function that you neglected
to mention:  It provides "nodes" at which objects have an opportunity
to contribute to decisions during interpretation of pathnames.  For
example, a directory node plays a very important organizational role,
a device driver node acts like a "portal", nodes act as mount points,
and so on.  Without an identifiable node structure the system would be
severely emaciated.  Indeed, Plan 9 exploits this even more heavily
than does UNIX.

Volume-Number: Volume 21, Number 145