Subject: Re: Improving the Unix API
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: tech-kern
Date: 06/28/1999 11:25:58
On Sun, 27 Jun 1999, der Mouse wrote:

> >> funlink makes no sense, unless [...]
> > I've wanted an fclri(fd)
> 
> This actually isn't as impossible as you make it sound.  Just provide a
> new vnode flag - VCLEARED, say - which is set on the vnode.  The
> underlying inode (or whatever, for other filesystems) is then blown
> away.  (This may require a new VOP_*.)  Attempts to do anything with a
> VCLEARED vnode error out.

We (4.4BSD) already have the revoke syscall, which will blow away the
in-memory vnode. So what you can do now is revoke("path") and then unlink
the path.

> > "{,f}chmod(path, mode);" certainly codes easier than 
> > "setfopt({path,fd}, SFO_CHMOD|SFO_{PATH,DESC}, mode)".
> 
> > And "getfopt(path, SFO_NOFOLLOW|SFO_PATH, sp);" vs "lstat(sp);"?  Or
> > "setfopt(fd, SFO_DESC|SFO_CHDIR, dir)" vs "fchdir(fd);"???
> 
> > [I hope it's obvious why the SFO_PATH and SFO_DESC would be necessary
> > in the aforementioned cases.]
> 
> Actually, it would have to be
> 
> 	setfopt(SFO_CHMOD|SFO_{PATH,DESC},{path,fd},mode)
> and
> 	setfopt(SFO_CHDIR|SFO_DESC,fd,dir)

One of the things we (NAS) have done and which I'll be pulling into NetBSD
soon is an extention to fcntl to make fcntl's which hit the filesystem. I
think this mechanism will give you the functionality you want.

Basically we're defining a part of the fcntl space to cover fcntl's which
hit the file system. They're like ioctl's except that they always hit the
fs, even for fifo and device nodes.

Right now NetBSD's fcntl defenition (which I thought matched POSIX) is
fcntl(int fd, int cmd, void * arg). (Some fcntl's can skip the arg
argument if they wish.) We're adding a test to bit 0x80000000 of cmd. If
it is set, we're dealing with a for-fs fcntl. In that case, we follow a
code path similar to ioctl processing (in/out/void processing with the
argument size encoded in the command), and end up making a VOP_FCNTL
call.

The command space is split as 0xFsssCCCC where F is argument encoding
(fcntl is for fs, has VOID, IN and/or OUT argument), sss is the argument
size, and CCCC is the actual command. One other difference between this
and ioctls is that we split the command space into half (test bit 0x8000
set or cleared), with half fs-independent and half fs-specific.
fs-independent commands have the same defenition for all FS's. They don't
have to impliment them, but if they do, they do it the same. ACL's would
be a good example of this. fs-specific ones do whatever the fs wants.

This extention doesn't address all of the concerns which started this
thread (you'd still need to open the file descriptor), but it'd give a way
to set & clear fs options without adding a new syscall.

We're using fs-specific fcntls to impliment a data migration file system,
and they work pretty well. :-)

Take care,

Bill