Re: [PATCH WIP 0/8] Draft: Alternative allocator support

[Danilo Krummrich <dakr@redhat.com>]

On Wed, May 01, 2024 at 11:32:02PM +0200, Miguel Ojeda wrote:
> On Mon, Apr 29, 2024 at 10:12 PM Danilo Krummrich <dakr@redhat.com> wrote:
> >
> > Please let me know what you think.
> 
> Thanks Danilo for implementing this.
> 
> I think we should explore options that avoid going back to
> `allocator_api` if possible (i.e. like for any other unstable
> feature).
> 
> In particular, `allocator_api` has been unstable for a while and it is
> not completely clear to me what the path forward there will be
> (especially with all the discussions around that particular unstable
> feature and previous efforts to make progress there, e.g. whether it
> would be fine for them to add more `try_*` methods and how to name
> them and the documentation concerns, and whether it may need to wait
> for other features like keyword generics / how exactly to avoid
> duplication of methods, and so on). It is also unclear if they could
> give us support on their side for flags per call site and so on.
> 
> So if we can find a way that does not use it and that does not have a
> performance penalty (or a big ergonomics penalty), then I think it is
> worth avoiding it.

Yes, I fully agree. As discussed, I will explore this option, get something
hacked up, post it and then we can see how it compares to the approach of this
series.

- Danilo

> 
> In fact, I would say what we really need is the flexibility to
> implement our own allocation APIs from scratch, including types like
> `Box`, `Vec`, `Arc`, etc. suited for particular kernel use cases, and
> giving those the methods that make sense in each case (whether or not
> wrapping/newtyping existing `alloc` types), rather than the ability to
> "just" customize the allocator for existing collections. To be fair,
> Rust is already willing to consider solutions for us on these matters,
> like they are doing with e.g. `derive(SmartPointer)`, which we really
> appreciate.
> 
> Cheers,
> Miguel
>