On 2026-02-19 16:24, Danilo Krummrich wrote: > On Thu Feb 19, 2026 at 4:44 PM CET, Joel Fernandes wrote: >> >> >> On 2/19/2026 10:27 AM, Joel Fernandes wrote: >>> On Thu, Feb 19, 2026 at 12:21:56PM +0100, Danilo Krummrich wrote: >>>> On Wed Feb 18, 2026 at 9:55 PM CET, Joel Fernandes wrote: >>>>> +RUST TO C LIST INTERFACES >>>> Maybe this should just be "RUST [FFI]" instead (in case Alex and you want >>>> to >>>> sign up for looking after FFI helper infrastructure in general)? >>> >>> Good idea, done. >> >> Actually, I am not sure we want to commit to entire RUST FFI infra though its >> pretty tiny right now. Most of this infra right now is clist, let us start >> with >> keeping it as is "RUST TO C LIST INTERFACES" ? Or we could make it "C LIST >> INTERFACES [RUST]" sections. > > 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. I feel that the FFI infra is the core responsibility of the top-level Rust entry, while specific stuff can be splitted out. Best, Gary > > I could imagine that we will find quite some more cases where an FFI > abstraction > layer makes sense; at some point it might even go the other way around. > > Once that happens, I think it would be good to have people looking after > intermediate FFI layers in general. But it does not have to be you of course. > > Maybe we can create the "RUST [FFI]" entry already with the following > constraint: > > RUST [FFI] > M: Joel Fernandes <[email protected]> (CLIST) > M: Alexandre Courbot <[email protected]> (CLIST) > L: [email protected] > S: Maintained > F: rust/kernel/ffi/
