On Wed, Dec 06, 2023 at 02:40:41PM +0100, Peter Zijlstra wrote: > On Wed, Dec 06, 2023 at 01:57:52PM +0100, Alice Ryhl wrote: > > On Wed, Dec 6, 2023 at 1:34 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > I can reimplement these specific functions as inline Rust functions, > > That would be good, but how are you going to do that without duplicating > the horror that is struct task_struct ? > > > but I don't think I can give you a general solution to the > > rust_helper_* problem in this patch series. > > Well, I really wish the Rust community would address the C > interoperability in a hurry. Basically make it a requirement for > in-kernel Rust. > > I mean, how hard can it be to have clang parse the C headers and inject > them into the Rust IR as if they're external FFI things. That's pretty much how Swift and Carbon are doing C (and C++) interop. Carbon: https://youtu.be/1ZTJ9omXOQ0?si=yiuLHn6o8RMezEZj Swift: https://youtu.be/lgivCGdmFrw?si=-x9Uva-_Y2x-JNBe The swift talk doesn't allude much to the codegen interop they're doing (still an excellent talk), but the carbon folks have adopted a model from Swift of doing interop at the IR layer. Those compilers link against clang to provide IR interop. Rust's bindgen crate links against clang to generate Rust stubs. At some point, someone on the Rust side will notice what Swift and Carbon are up to, realize they're probably already linking against libclang for C/C++ interop, and try just linking libclang into rustc itself.
