Subject: Re: CVS commit: src
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 08/28/2006 12:37:38
> > 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...)