Problems with Rust and C code interaction in the kernel:

• Mismatched types: Bindgen's translation between C and Rust types is platform-dependent and not one-to-one. Some important types like size_t and uintptr_t are typedefs, adding complexity. Implicit integer conversions in C lead to unnecessary type casts in Rust.
• Too many type casts: Clippy complains about redundant casts, but they are necessary on different architectures due to type mapping differences. Type names can also cause problems for type tags in CFI protection. The kernel defines char as unsigned, while Rust's c_char respects the architecture's sign convention.
• Overhead of helper functions: Rust-for-Linux project wraps C macros and inline functions, leading to performance issues. There are alternative approaches like changing the policy against reimplementing macros in Rust, transpiling C macros to Rust with c2rust (but it has issues), or using cross-language link-time optimization (LTO).

Proposed solutions:

• For types: Adopt a custom, fixed mapping for bindgen in the kernel to alleviate some problems. But it may not work for CHERI systems and has some edge cases.
• For helper functions: Use Clang to compile helpers.c into LLVM bytecode and perform LTO to inline helper functions across language boundaries. Add appropriate attributes to the LLVM bytecode file. Tested with existing Rust kernel code and showed a few percent speedup.

Challenges and discussions:

• Linking the resulting objects back into the kernel with duplicate symbols is a problem. Weak_odr linkage in LLVM might be a potential solution but requires C++ support in the kernel. GCC support is also discussed, but it has challenges due to differences in flag usage.