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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
