Subject: Re: CVS commit: src
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 08/23/2006 12:01:08
> > > 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_lookup_fileid(fileassoc_fileid_t, fileassoc_t);