Messages in this thread | | | Date | Thu, 21 Jun 2007 09:13:40 -0700 | From | "H. Peter Anvin" <> | Subject | Re: Adding subroot information to /proc/mounts, or obtaining that through other means |
| |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |