Subject: Re: metahook(9)
To: Bill Studenmund <email@example.com>
From: Brett Lymn <firstname.lastname@example.org>
Date: 06/17/2006 21:02:53
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).