Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> 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.

Who owns what opaque data?

It's all well and good to say that a layered file system can use it,
or that there's an interface to get and set it, but unfortunately that
doesn't say anything useful about intended semantics.

And all of that should be hashed out in detail before a major
modification to the OS's primary file system is put into the source
tree.


> 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.

It's not even obvious to me why it makes sense to export this
information from the kernel directly.

I can think of reasons you might want to, and i can think of things
user-land might do with it...  But i can also see many arguments,
esp. around mangement and 'ownership' of the data, that indicates that
only another, layered file system should export it to user-land.

What is the data protection and access control model here?  etc.?


There hasn't even been an adequate statement of goals and/or
functional requirements, let alone a justification of the design
and/or implementation, to get this type of file system and system
interface change into the tree, as far as i'm concerned.



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