> The reason why I implemented that way, is to less confuse the user and
> provide more flexibility. With my implementation, we have the ability
> to share any part of the tree, without bothering if it is a mountpoint
> or not. The side effect of this operation is, it ends up creating
> a vfsmount if the dentry is not a mountpoint.
>
> so when a user says
> mount --make-shared /tmp/abc
> the tree under /tmp/abc becomes shared.
> With your suggestion either the user will get -EINVAL or the tree
> under / will become shared. The second behavior will be really
> confusing.
You are right.
> I am ok with -EINVAL.
I think it should be this then. These operations are similar to a
remount (they don't actually mount something, just change some
property of a mount). Remount returns -EINVAL if not performed on the
root of a mount.
> Also there is another reason why I used this behavior. Lets say /mnt
> is a mountpoint and Say a user does
> mount make-shared /mnt
>
> and then does
> mount --bind /mnt/abc /mnt1
>
> NOTE: we need propogation to be set up between /mnt/abc and /mnt1 and
> propogation can only be set up for vfsmounts. In this case /mnt/abc
> is not a mountpoint. I have two choices, either return -EINVAL
> or create a vfsmount at that point. But -EINVAL is not consistent
> with standard --bind behavior. So I chose the later behavior.
>
> Now that we anyway need this behavior while doing bind mounts from
> shared trees, I kept the same behavior for --make-shared.
Well, the mount program can easily implement this behavior if wanted,
just by doing the 'bind dir dir' and then doing 'make-shared dir'.
The other way round (disabling the automatic 'bind dir dir') is much
more difficult.
> > Some notes (maybe outside the code) explaining the mechanism of the
> > propagations would be nice. Without these it's hard to understand the
> > design decisions behind such an implementation.
>
> Ok. I will make a small writeup on the mechanism.
That will help, thanks.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |