Re: [PATCH v3 00/10] Allocation APIs

[Danilo Krummrich]

On 4/26/24 12:31, Danilo Krummrich wrote:
> On Fri, Apr 26, 2024 at 06:32:26AM +0000, Benno Lossin wrote:

<snip>

> > So aside from being able to use `Vec` and `Box` etc, I don't think there
> > are any advantages to using `allocator_api`. The disadvantages are that
> > it's another unstable feature that we need to get stabilized in some
> > form. So it increases the amount of time it takes for us to be able to
> > support multiple versions of Rust.
> >
> > I think it's fine for you to experiment with the `allocator_api` and see
> > where that leads you. But when we discuss merging patches that enable
> > unstable features, we should be sure that the feature is truly needed.
> > And that it cannot be replaced by custom code (it also depends on how
> > complicated it is, but I think `allocator_api` would be simple enough).
>
> I agree, though I'm not asking to re-enable allocator_api necessarily.
>
> My original question regarding this series was what's the plan on how to
> implement alternative allocators given the changes of this series.
>
> This series clearly is a huge improvement, however, before it was quite clear
> how to implement alternative allocators. Now it's rather unclear.
>
> It's good that we discuss the options now and I'm also happy to contribute to
> the implementation, but I also think that within the context of this series we
> should give an answer to this question.

In order to get a little closer to an answer I sketched up a patch series [1] to
support alternative allocators again and added, besides the KernelAllocator itself,
VmAllocator as an example. The patches can also be found in this tree [2].

Please let me know what you think.

- Danilo

[1] https://lore.kernel.org/rust-for-linux/20240429201202.3490-1-dakr@xxxxxxxxxx/T/#u
[2] https://gitlab.freedesktop.org/drm/nova/-/tree/topic/allocator