On Tue, 23 Mar 1999, Paul Goyette wrote:

> Is the vnextops interface going to be sufficiently general to store
> (pointers to) arbitrarily large amounts of "opaque data" per file?
> Where would this info be stored, in "continuation inodes"?

Hmm. Minor nit. There are three things going on here.

1) By growing the ffs inode, we've given ffs some room to grow, say with
ACL's & such. Only ffs (and ffs-aware applications like fsck, dump,
restore) know about any such extra stuff

2) One of the things we've done with this space is reserve 96 bytes for
opaque data. The name gives a lot a way. All ffs does with this data is
store it, tell you if it's there, retrieve it, and clear it. Nothing else.

3) We've added a generic interface, which we're calling vnextops (name
certainly negotiable) which lets programs "do stuff" with a file. Like
ioctl's, but hitting the inode (ioctl's for a device node go to the device
driver for instance). The similarity is very close as I modeled the
vnextops syscall after ioctl. :-)

Right now the only defined vnextops are to test, get, set, and clear
opaque data.

Half the command space is reserved for fs-specific operations. So coda
userland daemons, or arla daemons, or whatever, could do coda, arla,
whatever-specific actions. :-)

I'm drawing the distinction as ffs can't use the opaque data for anything.
It's for overlay fs's or userland programs. Likewise the users of opaque
data can't do anything not supported in the vnode interface (like
arbitrarily allocating blocks). An overlay fs could certainly use opaque
data to refer to another inode, and store information there. But the fs
would have to do that. (and somehow make the so-used inode not show up
through its layer).

Take care,

Bill