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...
>
> 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.
Thanks,
Miklos
