On Fri, 2007-06-22 at 00:06 -0700, H. Peter Anvin wrote: > Ram Pai wrote: > > > > the second patch made a /proc/propagation interface which had almost the > > same fields, but also added fields to show the propagation type of the > > mount as well as pointers to its peers and master depending on the type > > of the mount. > > > > I think the consensus seems to have a new interface /proc/make-a-name > > which extends the interface provided by /proc/mounts but provides the > > propagation state of the mounts too as well as disambiguate bind mounts. > > Which makes sense. > > > > Why? It seems a lot cleaner to have all the information in the same > place. It is highly unfriendly to userspace to have to gather > information in a lot of places, plus it adds race conditions. > > It would be another matter if the format that we have now couldn't be > extended, but we need those fields (well, except the two zeros, but who > cares) *anyway*, so we might as well stick to the existing file, and > reduce the total amount of code and clutter. Ok. so you think /proc/mounts can be extended easily without breaking any userspace commands? well lets see.. 1. to disambiguate bind mounts, we have to add a field that displays the path to the mount's root dentry from the filesystem's root dentry. Agree? 2. For filesystems that do not have a backing store, it becomes hard to disambiguate bind mounts in (1). So we need to add a filesystem-id field. 3. if we need to add the propagation status of the mount we need a propagation flag added in the output. 4. To be able to construct the propagation tree, we need a way to refer to the other mounts, since some mounts are peers and some other mounts are master. Which means we need a mount-id field. Agree? If you agree to the above 4 new fields, it becomes challenging to extend /proc/mounts to incorporate these new fields without breaking any existing applications. > > > > BTW: what is the need for overmounted flag? Do you mean two vfsmounts > > mounted on the same dentry on the ***same vfsmount*** ? > > > > Maybe I'm not following the uses of your flags well enough to figure out > if that information can already been deduced. With the addition of the above 4 mentioned fields, I think one should be easily able to decipher which mnt-id is mounted on which mnt-id. no? maybe not. Well we will have to extend the mountpoint field to indicate the mnt-id in which the mountpoint resides. RP > > -hpa - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
