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

["Danilo Krummrich" <dakr@kernel.org>]

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.