On Wed, Aug 23, 2006 at 11:43:07AM +0900, YAMAMOTO Takashi wrote:
> > 
> > That use is purely internal to fileassoc and when something better
> > than ino_t comes along then this usage can change without an API
> > change.  This is exactly why the hint is a uint64_t not ino_t.
> 
> sounds nonsense.
> 

No, I said _that_use_ I have other uses for the interface, anyway, see
below.

> 
> please find a better way.
> 

At the moment the choices are still limited which makes things
difficult.

> an alternative would be just making fileassoc switch to use
> filehandles.

Unfortunately, without further work on filehandles this represents a
serious regression.  I know there has been a lot of good work done on
filehandles but there is a major hole in the fact that the NFS client
code does not support filehandles.

>  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.

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.  If this is an acceptable approach then the last major
obstacle to converting fileassoc to filehandle would be gone.

> 
> 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.  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.

-- 
Brett Lymn