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.
