Subject: Re: CVS commit: src
To: None <>
From: YAMAMOTO Takashi <>
List: tech-kern
Date: 08/23/2006 11:43:07
> > iirc, the interface was designed in the way that the implementation
> > can be switched to use something better than ino_t to identify
> > "files".
> >
> 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.

- if it's purely internal as you say, it should be static and shouldn't
  be exposed to the rest of kernel.
- how to create "hint" without casting from ino_t?
- you can't store a filehandle in uint64_t.

> > your change kills the idea.  please revert.
> > 
> I disagree - this particular use removes the requirement for a second
> call to VOP_GETATTR() when adding a new association.  Additionally it
> provides a mechanism for using fileassoc when:
> a) The caller is in a code path that cannot sensibly perform a

please find a better way.

an alternative would be just making fileassoc switch to use
filehandles.  an implementation of VFS_VPTOFH is likely more trivial and
context-safe than VOP_GETATTR.

> b) The caller wants to associate some other unique tag (i.e. NOT a
>    fileid) with a file.

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.