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