On Tue, 4 Jun 2024 at 10:28, Peter-Jan Gootzen <pgoot...@nvidia.com> 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
