On Mon Jan 08 2007 at 09:13:57 -0800, Chuck Silvers wrote:
> > Yes, that's more sensible.  But why do we have both NOCACHE and the
> > check here?  Seems like we could do DELETE || RENAME here and get rid
> > of NOCACHE in the rename namei() calls, for consistency.
> > 
> > I committed the above, we can tweak it more later.  thanks
> 
> I was going to check in the DELETE || RENAME version,
> but now that you point out the redundancy with NOCACHE,
> I'd rather move to using only the explicit NOCACHE flag
> and remove the implicit check on DELETE.  all this implicit stuff
> makes this far harder to understand and makes the more common usage
> of namei() (eg. just for opening a file) slower as well.
> I'll leave this for after we fix the rest of the bugs, though.

I guess if we decide we don't disallow RENAME caching in namei(), we imply
that file systems should handle RENAME caching properly.  And I'm pretty
some of them don't want to do it.  Since you're suggesting RENAME ==>
NOCACHE, I don't see why every caller should separately specify it.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"