Ram Pai wrote: > > 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. > No, I don't think so. I suspect, in fact, that as long as we add the new fields to the right (obviously) we should be fine. There aren't all that many users of /proc/mounts, and even fewer that don't use the library functions (getmntent et al.) -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
