Path: utzoo!attcan!uunet!cs.utexas.edu!jsq
From: donn@hpfcrn.fc.hp.com (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <13103@cs.utexas.edu>
Date: 2 Oct 90 16:16:54 GMT
References: <556@usenix.ORG> <557@usenix.ORG> <106697@uunet.UU.NET> <566@usenix.ORG> <107020@uunet.UU.NET> <107042@uunet.UU.NET>
Sender: jsq@cs.utexas.edu
Lines: 42
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)

I was thinking about this a bit more, and want to propose some food for
thought on the issue.

Classically, open() is a function that "opens a file descriptor", which
is where the name comes from.

However, if you think, rather, of open() as "translate from the (filesystem)
namespace this string, and give me a handle on the object" it actually makes
more sense.

The operations that can be performed on a file are the classical operators
applicable to such a handle.  However, some are forbidden or meaningless on 
some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
devices), and some have operations only applicable to them (ioctl on 
devices) and no other type.  I can easily imagine an object that had none
of the classical file operations applied to it.

Now, there is also nothing that requires that open() be the only function
that returns such a generic object handle.  Imagine (simple example) a
a heirarchical namespace that contains all possible character
bitcodes in the namespace.  Open() would not work very well because of the
null termination and slash rules.  However, I can imagine another function
that takes a char** as an argument, where each element is the name in
the next level of the heirarchy.  (With length in the first byte.)  It
would still return a classical file descriptor.  Similarly, maybe the
punctuation is different, or the notion of "root" is different; generalizing
open() to "give me a handle in a namespace" may be most useful.

I intend this not as any sort of proposal of something that should or should
not be done, but as an "icebreaker" in terms of thinking about the problem.

What are the further generalizations we need, how do they make sense and
fit together, and (the real test of success) what are some of the unexpected
benefits of the generalization?  (Granting that the "biggest" unexpected
benefit will show up "later".)

Donn Terry
Speaking only for myself.

Volume-Number: Volume 21, Number 167