Re: [patch 01/10] vfs: add path_create() and path_mknod()

[Al Viro <viro@ZenIV.linux.org.uk>]

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...