On Mon, May 05, 2008 at 03:43:15PM +0200, Enrico Weigelt wrote:
quoted text
> * Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > That you have quite forgotten about mounts.  
> 
> hmm, I though this would be done before the link_path_walk() 
> call happens ;-o

How on the earth...?  You don't know where will pathname resolution
get you, so how could you possibly handle mountpoint transitions prior
to it?

quoted text
> And if you use that option, you'll simply loose the ability
> of using mointpoints within this specific mount. This won't 
> affect any situation other than #1 && #2, IMHO this is better
> than no chance of fast lookups at all. Of course, an cleaner
> approach would be better, but it's IMHO not critical.

This is crap.  First of all, the logics is already overcomplicated.
_Then_ we have a problem of populating dcache for intermediates.

Besides, that's not what that thing is for - it's to allow local
caching (which we do) with revalidation of several components
at once.  _After_ VFS has decided that nothing interesting is in
the part of path it has cached.  Then the protocol allows to do
bulk Walk, verifying that all cached intermediates still match
the reality, all in one roundtrip.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/