Re: [PATCH v10 5/8] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes
Date: Wed Feb 25 2026 - 19:33:22 EST
> On Feb 25, 2026, at 3:20 PM, Joel Fernandes <joelagnelf@xxxxxxxxxx> 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