On Fri Feb 20, 2026 at 2:09 AM CET, Gary Guo wrote: > On 2026-02-19 16:24, Danilo Krummrich wrote: >> I feel like it makes a bit more sense to have an entry for the entire class >> of >> "RUST [FFI]" infrastructure. > > I don't think so. Most of the kernel crate is doing FFI. We have a `ffi` crate > defining FFI types, we have `CStr`/`CString` which in Rust std is inside > `std::ffi`, > etc.
The idea is not that everything that somehow has an FFI interface falls under this category, as this would indeed be the majority. The idea is rather everything that is specifically designed as a helper to implement FFI interactions. (Given that maybe just "RUST [FFI HELPER]"?) For instance, this would also apply to Opaque and ForeignOwnable. But also CStr and CString, as you say. But there's also lots of stuff that does not fall under this category, such as pin-init, alloc, syn, num, bits (genmask), fmt, slice, revocable, list, ptr, assert, print, arc, etc. There are also things that are more on the "partially" side of things, such as transmute, error or aref. > I feel that the FFI infra is the core responsibility of the top-level Rust > entry, > while specific stuff can be splitted out. I think the core responsibilities are compiler and general design topics, such as abstraction design, (safety) documentation, etc., as well as core language infrastructure, such as pin-init, syn, alloc, arc, etc. Given the definition "helper to implement FFI interactions" I feel like we have much more infrastructure that is not for this specific purpose.
