[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package for development of out-of-tree kernel modules written in Rust



Hi Miguel,

Sorry for the delay, I wanted to do some tests before answering.


On 06/04/25 23:21, Miguel Ojeda wrote:
So you want to build a kernel for architecture X in a host of
architecture Y, and then build an out-of-tree module for architecture
X in a host of architecture Z (possibly X)?

This is my understanding based on what the kernel maintainers wrote in this thread. At least in terms of enablement (i.e. wanting to support this scenario, not sure they actually need to do such builds).

As far as I have been told, the kernel generally requires that the
exact same toolchain is used to build out-of-tree modules as the main
kernel  -- so the same host/target pair should be used for both the
kernel build as the out-of-tree builds. Of course, things may happen
to work otherwise.

This is what I wanted to test. Using a different architecture's toolchain doesn't seem to work, even if the toolchain versions are the same. I built two twin kernels for arm64, first on an x86_64 host and then on an arm64 host. The toolchains were the exact same version-wise, but of course not the same in practice, being for two different hosts. Cross-compilation per se seems to work fine: I successfully cross-compiled the reference out-of-tree module using the build artifacts for the cross-compiled kernel and it loaded correctly on the target machine (after installing the cross-compiled kernel).

On the other hand, I was not able to compile the module on arm64 using the build files from the cross-compiled kernel. Since libmacros.so was compiled for x86_64, I tried using both the libmacros.so from the twin native build and a third libmacros.so which I cross-compiled using the same toolchain as the cross-compiled kernel. Neither of these worked, the build system failed to recognize the build artifacts:


```error[E0463]: can't find crate for `kernel`
 --> /home/noisycoil/Tmp/rust-out-of-tree-module/rust_out_of_tree.rs:5:5
  |
5 | use kernel::prelude::*;
  |     ^^^^^^ can't find crate

error: cannot find macro `pr_info` in this scope
  --> /home/noisycoil/Tmp/rust-out-of-tree-module/rust_out_of_tree.rs:35:9
   |
35 |         pr_info!("Rust out-of-tree sample (exit)\n");
```


Similarly, I was unable to cross-compile the module on x86_64 using the build files from the natively compiled kernel (again except for libmacros.so, which I took from the cross-build). In doing so I got the very same errors as above.

So I can confirm that builds in fact do not seem to work either way currently, the toolchain must be the exact same, as expected. In particular, it seems that the arch/config-(in)dependence of libmacros.so is not the main blocker here.

Is the reason that there is a build farm on architecture Y that builds
all the kernels for all X, and then you want users to be able to use
their architecture X to build out-of-tree modules for their kernel on
X? i.e. the X == Z case.

In Debian proper we build everything natively (32-bit builds usually being done on corresponding 64-bit machines). I cannot speak for the kernel maintainers, but my guess would be this discussion is in part motivated by simply wanting to support the cross-compilation scenario, in part by wanting to adapt to the current packaging scheme (some packages are for the host machine, others are for the target machine, libmacros.so technically is for the host machine so it should go in the corresponding package which is config-independent, etc.).

Cheers,
Miguel

Cheers!


Reply to: