Re: [RFC] fhandle implementation.

[Neil Brown]

On Saturday June 24, [e-mail] wrote:
> 
> 
> On Wed, 21 Jun 2000, Neil Brown wrote:
> 
> > Sorry, but I don't get this at all.
> > 
> > As far as I can see, filesystems need to know nothing about
> > mountpoints and vfsmounts and the like.  They simply present trees of
> > directories with otherthings (files/symlinks/etc) attached at various
> > points.  Any knowledge about how they are layered together is kept up
> > above in the VFS layer.
> 
> Right. Except that a notion of "subtree" is alien to fs. For VFS proper
> representation of that animal (subtree we want to deal with never
> trespassing its root) is vfsmount.

I think we are failing to communicate, so maybe would should just drop
this for now....
1/ When I look at "struct vfsmount", is see glue for sticking one part
   of one fs-tree to another part of another fs-tree.  That this
   defines are subtree is nearly an accident.  Any dentry defines a
   subtree (though a dentry for a file defines only a trivial
   subtree).
2/ If I were to pass a "struct vfsmount" to "resolv_fh", which bits
   would I use?  I cannot see a value in using any bit but
   "mnt_mountpoint", so why pass the rest?

> 
> > The one exception to this at present is follow_link which takes a
> > nameidata which contains a vfsmount.
> > However, from a quick scan of the source, there are precisely two
> > different things that filesystems do with nameidata.
> >   1/ ignore it completely
> >   2/ pass it to vfs_follow_link
> > which suggests (to me) that it probably shouldn't be passed at all -
> > that that is a separate thread :-).
> 
> One word: procfs.
> 

This is the bit that I just *had* to repond to.
Not meaning to denegrate you, or the code, or anything, I have to say
that this is truely comical. This is how it reads:

    We have to pass a vfsmount in a nameidata to follow_link.
    Why? Because of procfs.
    What does procfs do with it? It throws it away (path_release)!

Ok, so the less comical answer would be "because it does something
different with it", but to me, that makes it a different sort of
object which should be apparent in the inode_operations but I have
said that before.

> > Question: would it be possible for mountd to "Attach" to the mount
> > table that nfsd was using, or can shareing only happen through fork/clone?
> 
> Erm... What's wrong with having mountd spawned by nfsd?
> 

Uhmm... maybe.  It would be "different" but it might actually work
well.  I'll keep it in mind. Thanks.

NeilBrown