Subject: Re: CVS commit: src
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Brett Lymn <blymn@baesystems.com.au>
List: tech-kern
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
avoided.

> 
> 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()
safely.

> 
> you can implement the "generic hash table provider" and make fileassoc use it.
> (a too generic interface is likely useless, tho...)
> 

Yes, true.

-- 
Brett Lymn