Subject: Re: CVS commit: src
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 08/23/2006 11:43:07
> > 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.
- 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
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.