On Thu, Jun 15, 2006 at 11:08:20AM -0700, Bill Studenmund wrote:
> 
> You also are using identifiers (dev_t and inode_t) that really shouldn't 
> be used outside of the file system. We have cleaned-up abstraction 
> structures (file handles, for example) that remove much of the problem 
> wiht what you're doing. Their existence predates my use of NetBSD, and 
> actually they predate NetBSD. Yet you aren't using them.
> 

The blame for the usage of dev_t and inode_t can be laid at my feet.
When I started working on veriexec I looked for something that would
uniquely identify the file and found the va_fileid and va_fsid
elements in struct vattr.  Though they may be referenced as dev_t and
inode_t in the veriexec code they really are not used as anything
apart from tags to uniquely identify a file on a file system.  These
values are taken from the results of a VOP_GETATTR() call and are only
compared with results of other VOP_GETATTR() calls.  So, though the
numbers may have meanings in other contexts, in the context of
veriexec they are just a tuple of numbers to identify the file.
Unless I am mistaken, I believe that the metahook code is treating
dev_t and inode_t in the same manner - just as unique tags.

> 
> Plus, generation numbers are important, even for local disk stores. Since 
> you aren't storing pointers to the vnodes, use file handles.
> 

Any hints on using file handles?  I had a quick look around an the
only thing I could see was fhopen() and friends who use VOP_VPTOFH().
According to the man page for VOP_VPTOFH() it only works on NFS
exportable file systems.  Won't this preclude some file systems?
Including NFS? (since NFS mounts cannot be re-exported, indeed the
nfs_vptofh() and nfs_fhtovp() calls return EINVAL).

-- 
Brett Lymn