Re: [PATCH v10 5/8] rust: clist: Add support to interface with C linked lists

[Boqun Feng <boqun@kernel.org>]

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.

Regards,
Boqun

> 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.