On Fri, Jan 13, 2017 at 07:57:06PM +0000, Al Viro wrote: > On Fri, Jan 13, 2017 at 02:03:57PM -0500, J. Bruce Fields wrote: > > On Fri, Jan 13, 2017 at 10:52:54AM -0800, Christoph Hellwig wrote: > > > On Fri, Jan 13, 2017 at 12:39:12PM -0500, J. Bruce Fields wrote: > > > > If we're going to reject patches that don't implement get_parent (and I > > > > think we should), then we should replace "optional but strongly > > > > recommended" there by just "mandatory". Any objections? > > > > > > In theory yes - we'll just need an exception (or dummy implementation) > > > for in-memory file systems like tmpfs. > > > > Hm, so does get_parent just never get called for tmpfs because the > > parent's always there already? > > As the matter of fact, tmpfs *does* have a dummy ->get_parent(). > FWIW, the situation right now looks so: Thanks for the summary. > 1) most of the local filesystems: get_parent/fh_to_dentry/fh_to_parent. > efs, exofs, ext2, ext4, f2fs, fat, jffs2, jfs, ntfs, squashfs, udf, ufs are > that way. > 2) ditto, but with non-default ->encode_fh() (that's basically those > who need more than 32-bit inumber to get to an inode). Often enough those > have non-default ->get_name() as well - default one relies upon in-core > ->i_ino matching whatever getdents(2) puts into d_ino; besides, there might > be a faster way to search. Ones without ->get_name(): fat_nostale, fuse, > isofs, nilfs2, ocfs2, reiserfs. Ones with: lustre, btrfs, ceph, gfs2. > 3) shmem - essentially as (2), but there ->get_parent() is > a dummy and so's ->fh_to_parent(), the latter represented by NULL rather > than as an explicit stub. > 4) orangefs - no ->fh_to_parent, no ->get_parent. Not sure if > orangefs has a way to get khandle of parent by that of directory (i.e. > if it can open a disconnected directory by khandle and then obtain > a khandle of parent from it). They do include khandle of directory into > on-the-wire fhandle, but never actually use that part. Might be blind > copying of what other fs are doing, might be something they plan to do > but hadn't gotten around to. If it's the latter, that's yet another class > 2 (and it'll definitely need a ->get_name() then). > 5) befs - ->fh_to_dentry/->fh_to_parent, no ->get_parent. IIRC, > they simply don't have a way to find the parent by directory. > 6) cifs - stub ->get_parent(), NULL everything else, impossible > to use and what the hell is fs/cifs/export.c is doing in the tree, anyway? Dunno, I thought I tried to remove it once some time ago, but my memory may be wrong. It seems like nothing more than a trap for the unwary. --b. -- 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
