Re: [TECH TOPIC] Implementing malloc

On July 9, 2026 10:40:55 AM PDT, Miguel Ojeda <[email protected]> wrote:
>On Thu, Jul 9, 2026 at 7:13 PM Matthew Wilcox <[email protected]> wrote:
>>
>> What I really don't want to see is a whole pile of Rust changes to
>> accommodate having to pass GFP flags to memory allocations.  Would that
>> be a better vehicle for the discussion?
>
>Currently we already pass the GFP flags and support different allocators.
>
>For context, initially we used a vendored `alloc` crate, because we
>were trying to see if upstream could give us what we needed.
>
>Then in 2024 (v6.10) we were able to drop the vendored copy by using a
>workaround by Wedson that allowed us to pass the GFP flags and avoided
>our reliance on upstream's allocator unstable feature:
>
>  b6a006e21b82 ("rust: alloc: introduce allocation flags")
>
>Later that year (v6.13), we couldn't wait much more, so we ended up
>implementing our own `alloc` module and allocator support on our side
>by Danilo:
>
>  b7a084ba4fbb ("rust: alloc: add `Allocator` trait")
>
>Cc'ing rust-for-linux and Danilo.
>
>Cheers,
>Miguel
>
>

In case it was not obvious, my comment was meant to be ironic (reductio ad absurdum).

In fact, I'm surprised and worried to hear how recent this was. This underscores my main concern with Rust, which is that it seems to have *very* different stability criteria than the C code, where we are not allowed to require anything that hasn't been in gcc for 5-10 years, after which the clang people discover they never implemented it and so they ask for another 5+ years of keeping the old-syle or fallback code.