Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: comp.unix.wizards
Subject: Re: descriptors vs pathnames (was Re: getcwd() and friends.)
Message-ID: <1249@ncr-sd.SanDiego.NCR.COM>
Date: 13 Apr 89 05:59:23 GMT
References: <811@mtxinu.UUCP> <12625@swan.ulowell.edu> <13550@ncoast.ORG> <4457@psuvax1.cs.psu.edu>
Reply-To: Greg.Noel@SanDiego.NCR.COM (Greg Noel)
Organization: NCR Corporation, Rancho Bernardo
Lines: 28

In article <4457@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu
(Scott Schwartz) writes:
>... what Felix Lee and I are proposing ... is to add two new flags
>to open....  The flags are O_EXEC ... and O_OPEN ....

It's interesting to me how this thread is re-inventing the opaque directory
object proposed as part of the Secure Multics Project.  The essential point
of your proposal is to be able to acquire a handle on some component of the
file system tree, and then be able to perform operations on it.  In other
words, you are decoupling the name lookup from the operation.  The points
you are mooting have to do with the semantics of name lookup; you should
focus your effor there.

So what you need is a syscall that allows you to convert a textual name
into an opaque file handle; for the sake of discussion (no matter how it's
actually implemented), let's call it namei().  Thus, namei("/usr/tmp/foo")
produces a file handle for a (potentially non-existant?) file; then most
of the current system call that take a name could be defined in terms of this
new call.  (creat(filename, mode) would be fcreate(namei(filename, mode)).)
The new syscalls should modify the file handle passed it, not create a new
one, so the standard sematics can be easily simulated.

I don't think you need more than the one new syscall (or one new option to
the current open) in order to get the results you want; just consider the
file handle as opaque until it's consumed by another syscall, which has the
power to modify the attributes as necessary.
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd