Nouveau - Dec 2025 - [PATCH 4/4] build: rust: provide an option to inline C helpers into Rust

On Thu, Dec 4, 2025 at 12:11?PM Peter Zijlstra <peterz at infradead.org>
wrote:
>
> Right. Earlier I also proposed using libclang to parse the C header and
> inject that. This might be a little simpler, in that..
Yeah, that would be closer to the `bindgen` route in that `libclang`
gets already involved.
> ... if you build rustc against libclang they are necessarily from the
> same LLVM build.
So currently there are 3 "LLVMs" that get involved:

  - The one Clang uses (in LLVM=1 builds).
  - The one `rustc` uses (the LLVM backend).
  - The one `bindgen` uses (via libclang).

If that is all done within `rustc` (so no `bindgen`), then there may
still be `rustc` vs. Clang mismatches, which are harder to resolve in
the Rust side at least (it is easier to pick another Clang version to
match).

For those using builds from distros, that shouldn't be a problem.
Others using external `rustc` builds, e.g. from `rustup` (e.g. for
testing different Rust versions) it would be harder.

But I mean, anything approach that gets us into a better position is
welcome and I think requiring people to match LLVM everywhere should
be easier now that distributions are starting to enable Rust (even
Debian).

We have been talking about this since the very beginning of the
project -- e.g. I remember Wedson and I talking to Josh et al. about
improving the situation here (in particular, talking about integrating
a solution into `rustc` directly) long before Rust was merged into the
kernel. Even on things like a `rustc cc` or `cImport` like Zig (but
Zig moved on the other direction since then), which I recall Gary
having opinions about too.

There is also the question about GCC. A deeper integration into
`rustc` would ideally need to have a way (perhaps depending on the
backend picked?) to support GCC builds properly (to read the header
and flags as expected, as you mention).

And finally there is the question of what GCC Rust would do in such a
case. Things have substantially changed on the GCC Rust in the last
years, and they are now closer to build the kernel, thus I think their
side of things is getting important to consider too.

Cc'ing Emilio (`bindgen`), Antoni (GCC backend) and Arthur (GCC Rust)
so that they are in the loop -- context at:

    https://lore.kernel.org/rust-for-linux/20251204111124.GJ2528459 at
noisy.programming.kicks-ass.net/

Cheers,
Miguel

On 12/4/25 12:57 PM, Miguel Ojeda wrote:
> On Thu, Dec 4, 2025 at 12:11?PM Peter Zijlstra <peterz at
infradead.org> wrote:
>>
>> Right. Earlier I also proposed using libclang to parse the C header and
>> inject that. This might be a little simpler, in that..
> 
> Yeah, that would be closer to the `bindgen` route in that `libclang`
> gets already involved.
Yeah, so... there are existing tools (c2rust [0] being the actively 
maintained one IIUC) that in theory could do something like that 
(translate the bodies of the functions from C to Rust so that rustc 
could consume them directly rather than via LLVM LTO).

I think the intended use case is more "translate a whole C project into 
rust", but it could be interesting to test how well / poorly it performs 
with the kernel helpers / with a single header translated to Rust.

I personally haven't tried it because for work I need to deal with C++, 
which means that automatic translation to Rust is a lot harder / 
probably impossible in general. So for Firefox we end up relying on 
bindgen + cross-language LTO for this kind of thing, and it works well 
for us.

If I'm understanding correctly, it seems the kernel needs this extra bit 
of help (__always_inline) to push LLVM to inline C functions into rust, 
which is a bit unfortunate... But this approach seems sensible to me, 
for now at least.

FWIW Bindgen recently gained an option to generate inline functions [1], 
which could help avoid at least the bindgen ifdef in the patch series?

Anyways, it might be interesting to give c2rust a go on the kernel 
helpers if nobody has done so, and see how well / poorly it works in 
practice? Of course probably introducing a new dependency would be kind 
of a pain, but could be a good data point for pushing into adding 
something like it built into rustc...

Thanks,
  -- Emilio

[0]: https://github.com/immunant/c2rust
[1]: 
https://docs.rs/bindgen/latest/bindgen/struct.Builder.html#method.generate_inline_functions

On Thu, Dec 04, 2025 at 01:49:28PM +0100, Emilio Cobos ?lvarez
wrote:
> On 12/4/25 12:57 PM, Miguel Ojeda wrote:
> > On Thu, Dec 4, 2025 at 12:11?PM Peter Zijlstra <peterz at
infradead.org> wrote:
> > > 
> > > Right. Earlier I also proposed using libclang to parse the C
header and
> > > inject that. This might be a little simpler, in that..
> > 
> > Yeah, that would be closer to the `bindgen` route in that `libclang`
> > gets already involved.
> 
> Yeah, so... there are existing tools (c2rust [0] being the actively
> maintained one IIUC) that in theory could do something like that (translate
> the bodies of the functions from C to Rust so that rustc could consume them
> directly rather than via LLVM LTO).
> 
> I think the intended use case is more "translate a whole C project
into
> rust", but it could be interesting to test how well / poorly it
performs
> with the kernel helpers / with a single header translated to Rust.
> 
> I personally haven't tried it because for work I need to deal with C++,
> which means that automatic translation to Rust is a lot harder / probably
> impossible in general. So for Firefox we end up relying on bindgen +
> cross-language LTO for this kind of thing, and it works well for us.
> 
> If I'm understanding correctly, it seems the kernel needs this extra
bit of
> help (__always_inline) to push LLVM to inline C functions into rust, which
> is a bit unfortunate... But this approach seems sensible to me, for now at
> least.
> 
> FWIW Bindgen recently gained an option to generate inline functions [1],
> which could help avoid at least the bindgen ifdef in the patch series?
> 
> Anyways, it might be interesting to give c2rust a go on the kernel helpers
> if nobody has done so, and see how well / poorly it works in practice? Of
> course probably introducing a new dependency would be kind of a pain, but
> could be a good data point for pushing into adding something like it built
> into rustc...
I already tried c2rust as an alternative to this patch. It works okay
for many functions, but it's missing support for some features such as
asm goto, though this is fixable. But a larger issue is that some things
simply do not translate to Rust right now. For example:

* Atomics use the Ir operand.
* static_branch uses the i operand.

neither of which translate directly to Rust.

Alice