> > 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
>    VOP_GETATTR()

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.

YAMAMOTO Takashi