On Mon, 2024-06-03 at 10:24 +0200, Miklos Szeredi wrote:
> On Mon, 3 Jun 2024 at 10:02, Peter-Jan Gootzen <pgootzen@xxxxxxxxxx>
> wrote:
>
> > We would like to make a proposal regarding our idea for solving this
> > issue before sending in a patch:
> > Use a uint32_t from the unused array in FUSE_INIT to encode an
> > `uint32_t
> > arch_indicator` that contains one of the architecture IDs specified
> > in a
> > new enum (is there an existing enum like such?):
> > enum fuse_arch_indicator {
> > FUSE_ARCH_NONE = 0,
> > FUSE_ARCH_X86 = 1,
> > FUSE_ARCH_ARM64 = 2,
> > ...
> > }
> > Through this the host tells the FUSE file system which version of
> > fcntl.h it will use.
> > The FUSE file system should keep a copy of all the possible fcntl
> > headers and use the one indicated by the
> > `fuse_init_in.arch_indicator`.
>
> To be clear: you propose that the fuse client (in the VM kernel) sets
> the arch indicator and the server (on the host) translates constants?
Correct. Or in our case of virtio-fs, the FUSE server running behind the
virtio-fs device (possibly on another architecture) will translate
constants before sending them to the host.
>
> That sounds like a good plan.
>
> Alternatively the client would optionally translate to a common set of
> constants (x86 would be a good choice) and then the server would only
> need to know the translation between x86 and native.
We also considered this idea, it would kind of be like locking FUSE into
being x86. However I think this is not backwards compatible. Currently
an ARM64 client and ARM64 server work just fine. But making such a
change would break if the client has the new driver version and the
server is not updated to know that it should interpret x86 specifically.
>
> What about errno? Any other arch specific constants?
Yes there may be other arch specific constants that we need to consider.
I don't think errno is already an issue for us as there x86 and ARM64
are mostly the same, and everything in errno-base.h is already
compatible and are luckily most used in file systems.
But this proposed change would also help possible issues there.
>
> Thanks,
> Miklos
- Peter-Jan
