> 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).
Wrong. It's a "component of a namespace".
> 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?
->mnt_root, for that matter, but that's another story. Why the rest?
Because of ->mnt_count, basically.
> 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)!
WTF? path_walk() needs vfsmount. Period. If you are saying that
follow_link() should not do that (i.e. that it should be implemented via
readlink()) - eat flaming dea^Wprocfs where it can't be done that way.
Dentry alone does not define a position in namespace. It should go in pair
with vfsmount unless you are doing truely local operation. ->follow_link()
is not local by any stretch of imagination.
Mount the same filesystem twice. Have a symlink in its root with contents
being "..". Tell me (without vfsmount) where should it point.
> 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.
Talk with Linus. And get flamed. Just don't say that you had not been
warned.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/