On Thu, Sep 21, 2023 at 2:50 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Thu, 21 Sept 2023 at 12:31, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > Ok. Two follow up design questions.
> >
> > I used this in/out struct for both open/close ioctls,
> > because I needed the flags for different modes:
> >
> > struct fuse_backing_map {
> > int32_t fd;
> > uint32_t flags;
> > uint32_t backing_id;
> > uint32_t padding;
> > };
> >
> > I prefer to leave it like that (with flags=0) for future extensions
> > over the ioctl that inputs fd and outputs backing_id.
> > I hope you are ok with this.
>
> I'd prefer if backing_id was just a return value for open. Taking a
> struct as input is okay, and possibly it should have some amount of
> reserved space for future extensions.
>
> As for close, I don't see why we'd need anything else than the backing ID...
>
OK. dropped the inode bound mode, updated the example
to do server managed backing id for the rdonly shared fds.
Pushed this to the fuse-backing-id branches:
[1] https://github.com/amir73il/linux/commits/fuse-backing-fd
[2] https://github.com/amir73il/libfuse/commits/fuse-backing-fd
> >
> > The second thing is mmap passthrough.
> >
> > I noticed that the current mmap passthough patch
> > uses the backing file as is, which is fine for io and does
> > pass the tests, but the path of that file is not a "fake path".
> >
> > So either FUSE mmap passthrough needs to allocate
> > a backing file with "fake path"
>
> Drat.
>
> > OR if it is not important, than maybe it is not important for
> > overlayfs either?
>
> We took great pains to make sure that /proc/self/maps, etc display the
> correct overlayfs path. I don't see why FUSE should be different.
>
Now I will go have a think about how to ease the pain
in this area for vfs. I have some ideas...
Thanks,
Amir.
