On Mon, Jun 3, 2024 at 6:44 AM 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. For the purposes of virtio, it would definitely be preferable to define the FUSE protocol in a single, canonical, architecture-independent form. Ideally, this definition would be sufficient to implement a working virtio-fs client or server without referring to any Linux headers; currently, the virtio-fs spec just links to the Linux FUSE uapi header, which seems suboptimal for a protocol that is meant to be OS-agnostic (and has the problem of depending on arch-specific values, as discussed in this thread). One possible problem that I have noticed is that the interpretation of the max_pages field in fuse_init_out depends on the value of PAGE_SIZE, which could differ between host and guest even within the same architecture (e.g. ARM64 with 4K vs. 64K pages); architecture negotiation would not help with this particular problem. It would be nice if it could be specified in a canonical way as well, perhaps changing the definition so that it is always in units of 4096 bytes. Thanks, -- Daniel
