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
