Re: [RFC][patch series] vfsmount gutting

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

On Thu, Dec 08, 2011 at 05:19:57AM -0700, Matthew Wilcox wrote:
> On Thu, Dec 08, 2011 at 01:02:52AM +0000, Al Viro wrote:
> > 	OK, that's something I wanted to do for a long time - struct vfsmount
> > contains too much stuff that is strictily VFS-internal and not needed by
> > anything outside of a very small subset of VFS, at that.  As the matter of
> > fact, only 3 fields, 1 of them redundant, are used by code outside of that
> > area - it's mnt_flags ("how it's mounted"), mnt_root ("what dentry tree
> > is mounted here", assign-once thing) and mnt_sb (always equal to
> > mnt_root->d_sb, also assign-once, might or might not be not needed).
> 
> If only these 3 fields are used, why not make the definition of struct
> vfsmount entirely hidden, and add accessor functions for those three?

Code churn from hell, for starters.  And cost of non-inlined calls on some
fairly sensitive paths, but that's secondary.

It might turn out to be feasible, but the price is likely to include several
method prototype changes affecting filesystems all over the place.  E.g.
I really suspect that ->show_options() taking vfsmount had been a mistake.
Mine, at that.  It ought to take root dentry of (sub)tree instead.  No,
passing struct super_block * will _not_ work; the things that share superblock
between several mounts really want to know e.g. which of the snapshots it
is (nilfs2), etc.  The same probably goes for the rest of ->show...() methods.

Hell knows; if we end up in a place where what you said would be doable -
great, but I'd prefer to pull what can be pulled without messing with
fs code first.  Besides, this separation really makes sense - it's
"what part of fs this vfsmount refers to" vs. "how vfsmounts are connected
into mount trees".