Standards Update, IEEE 1003.4: Real-time Extensions

[Doug Gwyn]

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

In article <540 at usenix.ORG> brnstnd at 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