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

in the other words, you need something like the following, not uint64_t.
i don't think it's worth to have, at least for your purpose, tho.

	typedef struct fileassoc_fileid *fileassoc_fileid_t;
	fileassoc_fileid_t fileassoc_fileid_get(struct vnode *);
	void fileassoc_fileid_put(fileassoc_fileid_t);
	void *fileassoc_lookup_fileid(fileassoc_fileid_t, fileassoc_t);

YAMAMOTO Takashi