> On Feb 25, 2026, at 3:20 PM, Joel Fernandes <[email protected]> wrote: > > > >> On 2/25/2026 2:48 PM, Boqun Feng wrote: >>> On Fri, Feb 20, 2026 at 05:48:37PM +0100, Danilo Krummrich wrote: >>> 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]"?) >>> >> >> I feel like you may want to call it "interop" then, because it's "Rust >> doing something with interoperation on C data structure". If I >> understand you correctly, the category you referred here is the area >> that we could not simply call an FFI function to get the functionality >> from C side, but rather we need to make sure that we are interpret C >> data structure correctly to work with C side. > > Boqun has a point here: > https://en.wikipedia.org/wiki/Language_interoperability >
If we move forward with this wording we probably have to then rename the directory to rust/interop. That's probably not worth it I think since ffi and interop seem to be pretty closely related. I suggest let us keep it as helper wording for now as Danilo suggested. We can always change it later if need arises. -- Joel Fernandes
