On Fri, Feb 28, 2020 at 6:15 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Feb 28, 2020 at 05:24:23PM +0100, Miklos Szeredi wrote: > > On Fri, Feb 28, 2020 at 1:27 PM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Superblocks and mounts could get enumerated by a unique identifier. > > > > mnt_id seems to be good for mounts, s_dev may or may not be good for > > > > superblock, but s_id (as introduced in this patchset) could be used > > > > instead. > > > > > > So what would the sysfs tree look like with this? > > > > For a start something like this: > > > > mounts/$MOUNT_ID/ > > parent -> ../$PARENT_ID > > super -> ../../supers/$SUPER_ID > > root: path from mount root to fs root (could be optional as usually > > they are the same) > > mountpoint -> $MOUNTPOINT > > flags: mount flags > > propagation: mount propagation > > children/$CHILD_ID -> ../../$CHILD_ID > > > > supers/$SUPER_ID/ > > type: fstype > > source: mount source (devname) > > options: csv of mount options > > Oh, wonderful. So let me see if I got it right - any namespace operation > can create/destroy/move around an arbitrary amount of sysfs objects. Parent/children symlinks may be excessive... > Better yet, we suddenly have to express the lifetime rules for struct mount > and struct superblock in terms of struct device garbage. How so? struct mount and struct superblock would hold a ref on struct device, not the other way round. In any case, I'm not insistent on the use of sysfs device classes for this; struct device (488B) does seem too heavy for struct mount (328B). What I'm pretty sure about is that a read(2) based interface would be way more useful than the syscall multiplexer that the current proposal is. Thanks, Miklos
