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, 2024-06-04 at 10:45 +0200, Miklos Szeredi wrote:
> External email: Use caution opening links or attachments
> 
> 
> 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.
Great, so from the perspective of the client. If the server doesn't set
the FUSE_CANON_ARCH flag, it can be either:
1. The server is the same arch as the client. All will go well.
2. The server doesn't support the canonical format and it might be a
different architecture, and the troubles that we are currently dealing
with might occur.

Option 1 is detectable if fuse_init_out.minor >= CANON_ARCH_MINOR.
Option 2 is detectable if fuse_init_out.minor < CANON_ARCH_MINOR, not
sure yet what we could do with that knowledge (maybe useful in error
logging?).

> 
> > 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.

Great, I just wanted to prevent that we would need a monster any-to-any
arch translator, possibly on both sides.

> 
> Thanks.
> Miklos





[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