Al Viro wrote: > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: >> ... or, alternatively, add a subfield to the first field (which would >> entail escaping whatever separator we choose): >> >> /dev/md6 /export ext3 rw,data=ordered 0 0 >> /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0 >> /dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0 > > Hell, no. The first field is in principle impossible to parse unless > you know the fs type. > > How about making a new file with sane format? From the very > beginning. E.g. mountpoint + ID + relative path + type + options, > where ID uniquely identifies superblock (e.g. numeric st_dev) > and backing device (if any) is sitting among the options... The more I'm thinking about this, I think it's simplest to just add fields to the right of the existing /proc/*/mounts. Yes, the format is ugly, and it will end up being uglier still, but it's also ugly to have a bunch of different chunks of information formatted in different ways. So, the existing fields are: mnt_devname mnt_path filesystem_type options 0 0 ... and we'd want to add ... mnt_id propagation_info sb_dev path_to_fs_root As previously stated, in order to avoid having to expose kernel addresses to userspace, I suggest we simply add a counter field to struct vfsmount and use that for mnt_id. I'm not all that up on what is needed for propagation_info. I presume we want to be able to deduce the full mount lattice. One particularly important thing in my mind is to be able to distinguish overmounted filesystems (which I think is possible in the current setup only by ordering -- the filesystem on top I believe will end up last in /proc/mounts, but I don't know if there actually is anything that enforces that.) -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
