On Fri, Sep 11, 2020 at 12:25 PM Stefan Hajnoczi <[email protected]> wrote: > > On Wed, Sep 09, 2020 at 08:45:56PM +0200, Max Reitz wrote: > > This is a flag for fuse_attr.flags that indicates that the given entry > > resides on a different filesystem than the parent, and as such should > > have a different st_dev. > > > > Signed-off-by: Max Reitz <[email protected]> > > --- > > include/uapi/linux/fuse.h | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h > > index de94c11cfc3b..c034cdf8f5f4 100644 > > --- a/include/uapi/linux/fuse.h > > +++ b/include/uapi/linux/fuse.h > > @@ -417,6 +417,13 @@ struct fuse_file_lock { > > */ > > #define FUSE_FSYNC_FDATASYNC (1 << 0) > > > > +/** > > + * fuse_attr flags > > + * > > + * FUSE_ATTR_SUBMOUNT: File/directory is a submount point > > + */ > > +#define FUSE_ATTR_SUBMOUNT (1 << 0) > > If you respin, please add a little more detail here. How should clients
I'm just reviewing/queuing this, so no need to respin. > act when this flag is detected (which FUSE messages should they send to > deal with submounts)? Actually, no new messages, since the reply containing FUSE_ATTR_SUBMOUNT already refers to the submount root. I'll fix the description. And since there's no separate information for the actual mount point (userspace can't obtain it) AT_NO_AUTOMOUNT users become confused due to the dummy mountpoint becoming visible with all the wrong data. Maybe the fix is to force automount even with AT_NO_AUTOMOUNT. Will look into that. Thanks, Miklos _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
