Subject: Re: CVS commit: src
To: YAMAMOTO Takashi <email@example.com>
From: Brett Lymn <firstname.lastname@example.org>
Date: 08/28/2006 13:34:34
On Mon, Aug 28, 2006 at 12:37:38PM +0900, YAMAMOTO Takashi wrote:
> > Yes, I know this to be true but the nfs client code does not have the
> > vptofh call implemented.
> do you mean, if i implement it, you will revert this _hint hack?
Yes. Though I was thinking of doing it myself but if you are willing
that would be nice.
> of course, nfs client accociates nfs filehandles to vnodes.
> how can it work, otherwise?
That was what I was wondering. I had not looked into it before but
the more I looked the more I was puzzled as to why vptofh was being
> why do you want to use arbitrary tag?
currently, it is tied up with avoiding using VOP_GETATTR(). When
paging in pages from from disk all you get is a vnode pointer.
At this point I cannot do a VOP_GETATTR() to get a fileid to lookup
the veriexec entry. What I did was set up a hash table of veriexec
entry pointers hashed on the address of the vnode - this way I could
easily find the veriexec entry based on the vnode pointer. When I
added the _hint interface I discarded my private implementation and
used the fileassoc _hint. Looking at the file handle implementations
it would appear that I could replace this lookup with a VOP_GETFH()
> you can implement the "generic hash table provider" and make fileassoc use it.
> (a too generic interface is likely useless, tho...)