Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> We decided that an inode could contain at most one type of opaque
> (application specific) data. To do anything else would be sticking a file
> system in a file, and that's messy. :-)

I missed this the first time through.

> Also, the opaque data starts with a magic number, so that different
> applications (users of the data) can tell if a node has their data or not.
> Also, the magic numbers are reserved both normal and byte-swapped, so that
> applications can tell if the opaque data is theirs from an opposite-endian
> machine. :-)

So, basically, to draw several things from this:

* You can stack file systems which use the opaque data... but only one
deep!

* You'd better make sure you don't try to stack a single underlying
file system under multiple users of opaque data, or else things may
become Very Confused and/or unusable in any meaningful way.

* You can bypass the entire meaning of the opaque data by just
mounting the file system without mounting the 'overlay' which uses the
opaque data and then modifying the opaque data in various ways.



To me, this screams even more strongly that a generic vnextops() (or
whatever) is wrong, and that the right way to use the opaque data is
have it marked as 'opaque' in the generic ffs inode code, but provide
variants of FFS which do various things with it e.g. acls, provide
user-settable data, etc., and _enforce_ in the kernel, that only users
that understand the 'nature' of the opaque data can access the FS via
the file system interface.

i.e. have a 'user-available opaque data FFS' variant (which will let
you provide something like vnextops(), but in a less gross way 8-),
have an 'ffs with acl' variant, etc., that vary only in their handling
of the opaque data and which enforce 'ownership' of the opaque data on
a file system.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.