On 13/04/25 18:17, Miguel Ojeda wrote:
I am not sure I am following correctly the tests, but are you referring to rebuilding all the Rust artifacts (and not just the host ones)?
Yes. Only rebuilding the host ones -- that is, the macros -- did not work. To recap:
1. If the kernel is compiled natively on arm64a. building the OOT module on arm64 using the artifacts from the build obviously works
b. if the natively built artifacts are transferred to an x86_64 machine, and libmacros.so is replaced from a twin cross-build, cross-building the OOT module does not work. The compiler complains that the kernel crate and macros are not found
c. like 1b., but all Rust artifacts (i.e. rmetas too) are replaced from a twin cross-build, works
2. If the kernel is cross-built on x86_64a. cross-building the OOT module on x86_64 using the artifacts from the build works
b. if the cross-built artifacts are transferred to an arm64 machine, and libmacros.so is replaced from a twin native build, natively building the OOT module does not work. As in 1b. the compiler complains that the kernel crate and macros are not found
c. like 2b., but all Rust artifacts (i.e. rmetas too) are replaced from a twin native build, works
The builds are of 6.14.2 [1], done in Debian unstable containers with the latest toolchain versions available at this time. When I say a build worked I also mean the module correctly loaded on arm64. I have MODVERSIONS enabled in my config, but this is probably irrelevant in this context because, even if it wasn't, vermagic should be the same for native and cross builds here IIUC.
I think that would still be not generally supported by the kernel, since you still used a different host/target pair (i.e. different toolchains/binaries) -- if I understand correctly, your out-of-tree module ends up using `.rmeta`s that are different than those used for the main kernel since they come from a different build, even if they are all accepted by the Rust compiler since it built them all.
Correct. Yeah, I get this is unsupported by the kernel, I was just throwing things at the wall and see what sticks :-) Apparently what stuck is pretending rustc was never part of the equation and present the kernel image with a module built whatever way it works (in this case, by rebuilding the Rust bits with a non-matching compiler together with the OOT module). As far as I understand, this is the most support the kernel ever provided to this kind of stuff -- none, but once you get binaries to build these may turn out to be compatible if you're lucky enough.
Cheers![1] One caveat though: I wanted to try to load the modules without setting up other arm64 machines or VMs, so it was easier for me to use the Asahi fork. AFAICS they don't make changes to the build system nor module loading bits.