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 Tue, 4 Jun 2024 at 10:28, Peter-Jan Gootzen <pgootzen@xxxxxxxxxx> wrote:

> Will the FUSE_CANON_ARCH then be default/required in init_in from the
> new minor onwards?

No.  It just indicates that fuse can translate constants for this
particular arch.  Also I'm not sure non-virtiofs should advertise this
(though it shouldn't hurt).

> If so, a server/device that supports the new minor, would only need to
> support the canonical format.
> The fuse_init_in.arch_id is then only really used for the server/device
> to know the format of IOCTL (like Idan brought up).

Yes, for ioctl and also to reset the FUSE_CANON_ARCH in fuse_init_out
if the arches match.

> Who defines what the arch names are?

uname -m

It's already defined by the kernel.

> The last time an arch with its own constants was added was 12 years ago
> with ARM64. So the header wouldn't change often. Or is this something
> that the kernel avoids in general?

I don't care much, it's just that I don't think defining constants for
architectures really belongs in the fuse header.

> If arch_id is only used for IOCTL and the rest of the translation is
> through the canonical format with FUSE_CANON_ARCH, then I like this
> approach.

Yes.

> I think that if we introduce the canonical format, and also require the
> server or client to be ready to do translation from and towards the
> handshaked format specified in arch_id. Then it will be overly
> complicated on both sides without adding any value.

The point is to only translate to and from the canonical arch.

That doesn't mean that the kernel *has* to translate some obsolete
arch, because it's useless.  Only add complexity for things that are
actually useful.  And the proposed protocol supports that.

Thanks.
Miklos




[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux