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 arm64
a. 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_64
a. 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.
