Re: Addressing architectural differences between FUSE driver and fs - Re: virtio-fs tests between host(x86) and dpu(arm64)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux