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

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

On Thu, Dec 04, 2025 at 01:15:34PM +0000, Alice Ryhl
wrote:
> 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.
Right this. AFAIK Rust simply does not have feature parity with inline
asm. Them having picked a wildly different syntax for inline asm didn't
help either of course. But Rust is Rust, must have terrible syntax :-)