Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86145 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Package for development of out-of-tree kernel modules written in Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 01:30 +0100
    Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-02-26 12:50 +0100
      Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 13:20 +0100
        Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 14:00 +0100
          Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 15:20 +0100
            Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 19:30 +0100
              Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 22:00 +0100
                Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-27 18:40 +0100
          Re: Package for development of out-of-tree kernel modules written  in Rust Ben Hutchings <ben@decadent.org.uk> - 2025-02-26 19:20 +0100
            Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 19:30 +0100
              Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 20:10 +0100
                Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 20:20 +0100
                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-27 18:40 +0100
                Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-02 23:00 +0200
                  Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-02 23:30 +0200
                    Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-02 23:40 +0200
                      Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 00:50 +0200
                        Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-03 16:50 +0200
                          Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 19:30 +0200
                            Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-03 21:00 +0200
                              Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-03 23:30 +0200
                                Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-03 23:40 +0200
                                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-06 23:40 +0200
                                    Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-12 18:50 +0200
                                      Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-13 13:40 +0200
                                        Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-13 17:40 +0200
                                          Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-13 18:40 +0200
                                            Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-04-13 20:30 +0200
                                    Re: Package for development of out-of-tree kernel modules written  in Rust Ben Hutchings <ben@decadent.org.uk> - 2025-04-16 17:40 +0200
                                      Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-05-03 17:10 +0200
                                Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-04-04 11:20 +0200
                                  Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-04-06 23:40 +0200
            Re: Package for development of out-of-tree kernel modules written in Rust Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> - 2025-02-26 19:40 +0100
        Re: Package for development of out-of-tree kernel modules written in  Rust NoisyCoil <noisycoil@disroot.org> - 2025-02-26 14:40 +0100
        Re: Package for development of out-of-tree kernel modules written in  Rust Bastian Blank <waldi@debian.org> - 2025-02-26 14:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#86727

On Thu, Apr 3, 2025 at 8:33 PM Bastian Blank <waldi@debian.org> wrote:
>
> What the heck is this good for, where config dependency would be useful?

C macros in the kernel use the kernel config all the time, why would
this be different?

What is the root issue here?

> So, either "macros" is static and unchanging, then we can just build it
> and don't care.  Or it is dynamic, then it needs to be built next to the
> external module and not be shipped at all.

What "external module" are you referring to?

Thanks!

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On 03/04/25 23:08, Miguel Ojeda wrote:
> On Thu, Apr 3, 2025 at 8:33 PM Bastian Blank<waldi@debian.org> wrote:
>> What the heck is this good for, where config dependency would be useful?
> C macros in the kernel use the kernel config all the time, why would
> this be different?
> 
> What is the root issue here?

I think the key issue here is Debian wants to support cross-compiling 
out-of-tree kernel modules, but doing so with Rust modules requires one 
to have libmacros.so compiled and packaged for the build architecture, 
which in the context of cross-compilation is different than the target 
architecture. Stuff for the build architecture is config-independent in 
Debian's packaging and should probably remain so, as otherwise one would 
need to build such stuff for every single build architecture + target 
configuration (and arch) combination supported by Debian, which doesn't 
scale up, if at all possible.

The difference with C is C does not compile macros into shared 
libraries, so this issue does not arise. If libmacros.so (and more 
generally, for the future, every proc macro) could be compiled not only 
at kernel build time (which I understand is necessary anyway), but also 
recompiled while the out-of-tree module is being compiled, then this 
issue would not arise for Rust either. One could simply ship the headers 
package without the proc macros, and rebuild the proc macros when needed.

[toc] | [prev] | [next] | [standalone]

#86764

On Thu, Apr 3, 2025 at 11:32 PM NoisyCoil <noisycoil@disroot.org> wrote:
>
> I think the key issue here is Debian wants to support cross-compiling
> out-of-tree kernel modules,

I see, that sentence explains it, thanks!

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)?

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.

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.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

#86852 — 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!

[toc] | [prev] | [next] | [standalone]

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

On Sat, Apr 12, 2025 at 06:46:31PM +0200, NoisyCoil wrote:
> 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.

Okay, so all output of this step is only usable without any change to
the environment.  So we can only ship rust source in any way and the
kernel module make stuff needs to rebuild anything for the external
modules.

Bastian

-- 
Vulcans never bluff.
		-- Spock, "The Doomsday Machine", stardate 4202.1

[toc] | [prev] | [next] | [standalone]

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

On 13/04/25 13:14, Bastian Blank wrote:
> So we can only ship rust source in any way and the
> kernel module make stuff needs to rebuild anything for the external
> modules.

Yep, this seems to work [1]. The two tests I did are:

1. Native build on arm64. Installed the build on amd64, replaced the 
Rust files (rmeta and libmacros) with ones obtained by cross-compiling 
the same kernel with the same config on amd64. Pointing KDIR to the 
natively-built /usr/src/linux-headers with the replaced Rust files 
correctly builds the OOT module, and the module correctly loads on arm64.

2. Cross-build on amd64. Installed the build on arm64, replaced the Rust 
files with those from the twin native build. Same as above, the module 
builds and correctly loads on arm64.

This seems to be the way to go, although my limited testing may well be 
neglecting unknown failure modes.


[1] At least with MODVERSIONS enabled. Not sure what would happen with 
MODVERSIONS disabled, perhaps nothing, as long as the kernel version 
remains the same?

[toc] | [prev] | [next] | [standalone]

#86880

On Sun, Apr 13, 2025 at 5:36 PM NoisyCoil <noisycoil@disroot.org> wrote:
>
> 1. Native build on arm64. Installed the build on amd64, replaced the
> Rust files (rmeta and libmacros) with ones obtained by cross-compiling
> the same kernel with the same config on amd64. Pointing KDIR to the
> natively-built /usr/src/linux-headers with the replaced Rust files
> correctly builds the OOT module, and the module correctly loads on arm64.
>
> 2. Cross-build on amd64. Installed the build on arm64, replaced the Rust
> files with those from the twin native build. Same as above, the module
> builds and correctly loads on arm64.

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)?

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.

Nice to hear that worked here, though :)

Thanks a lot for all the tests you performed! I really appreciate it.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2025-04-06 at 23:21 +0200, Miguel Ojeda wrote:
> On Thu, Apr 3, 2025 at 11:32 PM NoisyCoil <noisycoil@disroot.org> wrote:
> > 
> > I think the key issue here is Debian wants to support cross-compiling
> > out-of-tree kernel modules,
> 
> I see, that sentence explains it, thanks!
> 
> 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)?
> 
> 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.

I don't see why there would be a problem with mixing objects built using
native and cross- C compilers with the same target and version.  (Unless
you enable gcc plugins, which we don't.)

> 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.

Official Debian binary packages are built natively, but there is also a
standard way to cross-build them and the kernel source package supports
this.  The resulting binary packages should be functionally identical.

We also try to give users the option to cross-build or natively build
out-of-tree modules, independently of that.  We apply a patch to always
define CROSS_COMPILE according to the target architecture.  (This works
even for the native case because e.g. x86_64-linux-gnu-gcc exists as a
native compiler on amd64.)

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
                                                           - Bill Gates

[toc] | [prev] | [next] | [standalone]

#87336

On Wed, Apr 16, 2025 at 5:36 PM Ben Hutchings <ben@decadent.org.uk> wrote:
>
> I don't see why there would be a problem with mixing objects built using
> native and cross- C compilers with the same target and version.  (Unless
> you enable gcc plugins, which we don't.)

It may work, but as far as I was told, it is not supported.

> Official Debian binary packages are built natively, but there is also a
> standard way to cross-build them and the kernel source package supports
> this.  The resulting binary packages should be functionally identical.

I see -- thanks for the details Ben.

Some news related to this: the other day I needed the kernel config in
the procedural macros in order to do conditional compilation based on
the compilers features/version (which is how we usually do it in the
rest of the code), which may land on v6.16 or v6.17.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On Thu, Apr 03, 2025 at 11:08:08PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 3, 2025 at 8:33 PM Bastian Blank <waldi@debian.org> wrote:
> > What the heck is this good for, where config dependency would be useful?
> C macros in the kernel use the kernel config all the time, why would
> this be different?

C macros are read by the preprocessor shipped in the compiler.  The
preprocessor changes it's behaviour depending on the input files.
However you don't recompile the preprocessor depending on the kernel
config.

But this is not what the macros crate is.  This crate _is_ a custom
preprocessor.  So, if it just reads the C macros the same way a C
preprocessor would, during compilation of the final result, then we
don't have a problem.

> What is the root issue here?

The root issue is:  libmacros.so, the output file, must be independent
from the kernel config.

> > So, either "macros" is static and unchanging, then we can just build it
> > and don't care.  Or it is dynamic, then it needs to be built next to the
> > external module and not be shipped at all.
> What "external module" are you referring to?

The one you build with "make M="

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!

[toc] | [prev] | [next] | [standalone]

#86763

On Fri, Apr 4, 2025 at 11:00 AM Bastian Blank <waldi@debian.org> wrote:
>
> C macros are read by the preprocessor shipped in the compiler.  The
> preprocessor changes it's behaviour depending on the input files.
> However you don't recompile the preprocessor depending on the kernel
> config.

I am aware of how C macros are traditionally handled, thank you, but
that is not what I was asking. My question was in relation to yours:

    What the heck is this good for, where config dependency would be useful?

It is pretty easy to see why it would be useful -- for instance, we
would have less (and thus more readable) generated code, as well as
faster macros too.

> The root issue is:  libmacros.so, the output file, must be independent
> from the kernel config.

That is not the root issue. That is a constraint you have.

And I don't see why you say it is a "must" -- we could have a way to
rebuild the required proc macros that out-of-tree modules need on the
fly, for instance, if we end up supporting that use case.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

#86164

On Wed, Feb 26, 2025 at 7:11 PM Ben Hutchings <ben@decadent.org.uk> wrote:
>
> This shouldn't go in a linux-headers package, because we aim to support
> cross-builds of modules.  If it doesn't depend on the kernel
> configuration (aside from CONFIG_RUST being enabled) then it belongs in
> linux-kbuild.

Hmm... Right now it doesn't, but it could, i.e. I don't think we want
to commit to never using the config in proc macros.

Cheers,
Miguel

[toc] | [prev] | [next] | [standalone]

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

On 26/02/25 14:22, Bastian Blank wrote:
>> case one can just add the Rust bits there. But I still think the Rust bits
>> should be installed in /usr/lib [1] instead of /usr/src.
> There is no need to get picky, sorry.

No need to be sorry, this is the kind of feedback I am looking for. If 
you confirm you are fine with linux-headers-@abiname@@localversion@ 
installing binary files (including shared libraries) under /usr/src then 
that's what I'll do, and there will be no need for new packages. I had 
assumed this shouldn't be done (and I personally frown upon this, but 
this is of course matter of opinion). My assumption however can be 
wrong, and in the end my main interest is shipping these files in *some* 
kernel package. Which one is not that important to me.

[toc] | [prev] | [next] | [standalone]

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

On Wed, Feb 26, 2025 at 01:13:45PM +0100, NoisyCoil wrote:
>                               Unless you are fine with
> linux-headers-@abiname@@localversion@ also installing binary files, in which
> case one can just add the Rust bits there.

The headers package includes many generated files that can't be
considered source.  The circumstance that that consist of readable text
does not make them source.

> case one can just add the Rust bits there. But I still think the Rust bits
> should be installed in /usr/lib [1] instead of /usr/src.

There is no need to get picky, sorry.

Bastian

-- 
The more complex the mind, the greater the need for the simplicity of play.
		-- Kirk, "Shore Leave", stardate 3025.8

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel

csiph-web