On Mon, Jun 03, 2024 at 04:56:14PM +0200, Miklos Szeredi wrote: > On Mon, Jun 3, 2024 at 3:44 PM Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > > > > On Mon, Jun 03, 2024 at 11:06:19AM +0200, Miklos Szeredi wrote: > > > On Mon, 3 Jun 2024 at 10:53, Peter-Jan Gootzen <pgootzen@xxxxxxxxxx> wrote: > > > > > > > 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. > > > > > > This would need to be negotiated, of course. > > > > > > But it's certainly simpler to just indicate the client arch in the > > > INIT request. Let's go with that for now. > > > > In the long term it would be cleanest to choose a single canonical > > format instead of requiring drivers and devices to implement many > > arch-specific formats. I liked the single canonical format idea you > > suggested. > > > > My only concern is whether there are more commands/fields in FUSE that > > operate in an arch-specific way (e.g. ioctl)? If there really are parts > > that need to be arch-specific, then it might be necessary to negotiate > > an architecture after all. > > How about something like this: > > - by default fall back to no translation for backward compatibility > - server may request matching by sending its own arch identifier in > fuse_init_in > - client sends back its arch identifier in fuse_init_out > - client also sends back a flag indicating whether it will transform > to canonical or not > > This means the client does not have to implement translation for every > architecture, only ones which are frequently used as guest. The > server may opt to implement its own translation if it's lacking in the > client, or it can just fail. From the client perspective: 1. Do not negotiate arch in fuse_init_out - hopefully client and server know what they are doing :). This is the current behavior. 2. Reply to fuse_init_in with server's arch in fuse_init_out - client translates according to server's arch. 3. Reply to fuse_init_in with canonical flag set in fuse_init_out - client and server use canonical format. From the server perspective: 1. Client does not negotiate arch - the current behavior (good luck!). 2. Arch received in fuse_init_out from client - must be equal to server's arch since there is no way for the server to reject the arch. 3. Canonical flag received in fuse_init_out from client - client and server use canonical format. Is this what you had in mind? Stefan
Attachment:
signature.asc
Description: PGP signature
