Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> > 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.
> 
> Why are you so angry with vnextops? All it does is permit programs to ask
> the fs to do things to a file's vnode. And to protect against syscall
> profusion.

I've not "angry" with it.

(1) the name blows.  what does "vn" mean in a user-land context?
userland doesn't know about vnodes, user-land knows about files.

(2) i believe that the user-land interface could easily be exported a
different, better way that doesn't involve a new syscall.
e.g. fcntl().  fcntl() is "file control".  it's ioctl-like already...

(3) per my previous comments (re: ownership/use of the opaque data),
i'm (a) not convinced that this functionality should be exported to
user-land _at all_, and (b) if it should, that it should be exported
by anything other than layered FSes which are kind enough to allow
access.

In other words, completely bogus name, and quite probably very bad
design.


> Also, where in the kernel should we enforce access to the opaque data? To
> ffs, it's just a 96-byte blob in the inode which might or might not be
> there.

To be honest, i don't know.  but you should, and your design
document/proposal should state it, and why.

Given that the opaque data obviously does have critical meaning to at
least some parts of the kernel and/or system (the in-kernel overlay
file system, or the user-land programs which depend on its meaning),
it seems fairly obvious that it _has_ to have some type of access
control.

Yet you've not even indicated that you've as much as thought about the
issue!


> My thought is that storing state for an overlay fs is orthogonal to having
> acl's. :-)

That's all well and good, but really, acls were only one example of
the need to make sure the data is protected and access controlled in a
reasonable manner.

the 'opaque data' might be as critical to an overlay file system as it
would have been in an acl-providing overlay in my example.  Further,
until the underlying file system provides ACLs, i think your design
for this overlay-usable opaque data is bogus unless it's possible to
implement ACLs using the opaque data.  I.e. if i can't implement ACLs
using it, or other similar functionality (really, all the
functionality i can see maps to the same sets of data integrity and
access requirements that ACLs would require), then your design is
bogus.



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