Re: [PATCH v3 00/10] Allocation APIs

[Danilo Krummrich <dakr@redhat.com>]

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@redhat.com/T/#u
[2] https://gitlab.freedesktop.org/drm/nova/-/tree/topic/allocator