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

[Joel Fernandes]

On 2/20/2026 11:48 AM, 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 do tend to agree with Danilo on this. Unless someone yells, I will change
the maintainer entry to "RUST [FFI HELPER]" for the next spin.

thanks,

--
Joel FErnandes


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