On Thu, Dec 4, 2025 at 6:27 AM Peter Zijlstra <[email protected]> wrote: > > 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 <[email protected]> > > > > 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.
I took a shot at `c2rust` as well, the summary was that `c2rust` was missing: * Asm goto support * __builtin_types_compatible_p * Deduced types * __count * _Generic I was adding hacky implementations along the way to see if things could be made to work, but the %l and %i missing in Rust itself that Alice pointed out were not things that could really be worked around. I also think that the bitcode-based approach is more future proof - the kernel may pick up new C features that `c2rust` hasn't yet learned about. If `clang` is in charge of generating the bitcode for the to-be-inlined helpers, we don't risk any desync in terms of what features are supported either by `c2rust` or by `rustc` relative to what's in use by the rest of the kernel. > > 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 :-)
