Brett Lymn wrote:
> 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.

i agree with brett here; when we thought how to address this issue with
the new fileassoc code that veriexec uses i suggested we add a few
hinted calls -- although specifically for that purpose, but to be
politically correct, the man page suggests they can be used to "bypass
internal calculation for critical code paths".

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

-e.

-- 
Elad Efrat