> >  an implementation of VFS_VPTOFH is likely more trivial and
> > context-safe than VOP_GETATTR.
> > 
> 
> 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?

> I have had a bit of a look at this and it seems to me that the nfs
> server provides a filehandle which could be useful.  If we associate
> this filehandle with the vnode on the nfs client then VFS_VPTOFH
> should be easy.

of course, nfs client accociates nfs filehandles to vnodes.
how can it work, otherwise?

> If this is an acceptable approach then the last major
> obstacle to converting fileassoc to filehandle would be gone.

and you are introducing another obstacle.

> > it sounds like an abuse.  if you want to associate data to an
> > arbitrary "unique tag" other than a file, you shouldn't use this interface.
> > 
> 
> No, you misunderstand.  I want to associate a file to an arbitrary tag
> that is not a fileid as a separate fileassoc table.

why do you want to use arbitrary tag?

> It seems odd to
> me that we allow multiple fileassoc tables yet all of them do the same
> thing?  To me, it seems we can make fileassoc more of a generic hash
> table provider instead of there being multiple implementations of
> basically the same thing in the kernel.

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

YAMAMOTO Takashi