On Tue, Aug 22, 2006 at 07:20:33AM +0900, YAMAMOTO Takashi wrote:
> 
> 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.

> 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()
b) The caller wants to associate some other unique tag (i.e. NOT a
   fileid) with a file.

Both these instances are used in the per-page veriexec code.

As I have said before I fully support moving away from fileid as a
unique identifier, I would like to use filehandle but it is "not there
yet" and, unless someone else steps up (I may take this on), filehandle
is not going to move forward for some time yet.  This makes things
very awkward to progress.

-- 
Brett Lymn