On Tue, 23 Mar 1999 23:34:33 -0500 
 Ted Lemon <mellon@isc.org> wrote:

 > > These flag bits would indicate what extra goddies are there, like
 > > Y2038-safe dates
 > 
 > This doesn't belong in the opaque data field - that would simply be a
 > duplication, and wouldn't work if you needed the opaque data for
 > anything else, thus rendering the opaque data useless.   Fixing the
 > times on the inode pretty much requires a change in the existing inode
 > structure.

You're right, they don't.

That's why there are a few spare u_int32_t fields _IN ADDITION TO_ the
opaque data section.  And flags indicate which of those to-be-defined-but-
as-yet-reserved fields are valid.

 > > support for more than 32-bits worth of blocks (I think that was one
 > > of the things Perry mentioned, but I'm not sure if our indirect
 > > block system would support that?)
 > 
 > This is another thing that doesn't belong in the opaque data.

You're right.  "See above."

 > > support for acl's, etc. As features arrive, dump, restore, ffs, &
 > > friends get taught about them.
 > 
 > That's great, but the opaque data isn't a place where any of these
 > features can go - you already have a use for the opaque data.  Any one
 > of these uses would prevent the other uses.  This simply doesn't make
 > sense.

You're right.  "See above."

Sigh, I'm getting really frustrated with this thread.  So, I'm going
to just state the obvious, for those which haven't clued in yet:

	The opaque data is not going to be used by LIFFS.

IT'S OPAQUE.  It's for use by a client of the LIFFS.  That client may be
a stacked file system, a userland application, or both.

In the SPECIFIC case we're dealing with here, it's both.

	(1) The opaque data area in the LIFFS inode contains additional
	    metadata needed by the DMFS file system, including a 128-bit
	    file ID (used to lookup file state in a separate database),
	    residency status flags, a database user id, and additional
	    atime/mtime records that the upper layer node will present.

	(2) The DMFS userland portion (the archive/restore agent) needs
	    to be able to query and change the state of the DMFS metadata.
	    In the old Convex system, there are additional DMFS-specific
	    system calls.  In order to make this generic enough so that
	    most of the code could be fed back to NetBSD, we came up
	    with vnextops().

The reason you can't use ioctl() to perform these functions is that
DMFS _may need to operate on a VCHR/VBLK vnode_, and ioctl would
erroneously pass all that on to specfs.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>