On Wed, Apr 02, 2008 at 09:37:01PM -0400, Erez Zadok wrote: > Since you've hinted of major vfs changes post-25, here's my take. > > Right now I (and to a similar extent ecryptfs too) needs to keep track of > vfsmounts for various reasons: > > - to grab a reference so the lower filesystems/mounts won't disappear on me Umm... Strictly speaking that's not true; you can grab an active reference to superblock and then superblock will stay. vfsmount is usually more convenient, but that's it. > - to pass it to dentry_open (opening the lower file) > - some fs ops pass a vfsmount (umount_begin, show_options) Thank Trond for the former, BTW ;-) Both methods will be back to sanity; for umount_begin() the only obstacle is cifs mess, where we do unconditional (and bogus) work at each umount(2). With that fixed, we'll be back to calling it only for forced umount and passing it only superblock. ->show_options() can and should revert immediately after 2.6.25; thanks for pointing that one out. > - some fs ops or vfs helpers require a nameidata or struct path which embed > a vfsmount inside *ONLY* ->follow_link(). Which has to, by definition... The rest will be gone by .26. > - sometimes it's ok to pass NULL for those things, sometimes it's not ok See above. This crap will be gone. For ->follow_link() nobody is allowed to pass NULL as nameidata, period. > In the longer run, is there a way that a stackable f/s could traverse the > namespace below it w/o knowing or caring how they are composed (assorted r-w > and r-o bind mounts and such)? Eh? Explain, please... -- 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
