Re: [git pull] more vfs bits

[Al Viro]

On Sat, Feb 21, 2015 at 05:14:37PM -0800, Linus Torvalds wrote:

> .. and this is the one that makes no sense to me.
> 
> It's the common case, and I don't see how it *possibly* adds any
> value. The "I want the inode of this dentry" is traditionally done as
> "dentry->d_inode".
> 
> What is the *upside* of the wrapper?

AFAICS, having yet-to-be-annotated cases stick out...

BTW, the goal this series is aiming at probably ought to be spelled out
more clearly: there's a bunch of stacking-related stuff (overlayfs and
ecryptfs in the tree, at least unionmount and aufs outside) that could
benefit from having the notion "this dentry covers that stack of
dentries from underlying fs layers" supported sanely by VFS, rather
than having it open-coded in one way or another.  And every place like
that ends up in incestous relationship with VFS; it was annoying while
it had been just ecryptfs, but it's getting worse now.  Moreover, the
details of behaviour overlayfs ends up having to rely upon are both
potentially brittle *and* leaving quite a few things not working properly
(starting with /proc/*/fd/* readlink, etc.)  The goal behind
all that massage is to have that notion (stacking) understood by VFS.

And no, it's not related to the question of annotating ->d_inode accesses -
just something that wasn't quite obvious from David's description.
IMO it's worth spelling out somewhere in this thread...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/