Received-SPF: pass (google.com: domain of linux-kernel+bounces-163008-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <e29f22c5-3d65-4d60-af0b-a440b6746dba@redhat.com>
Date: Mon, 29 Apr 2024 22:14:35 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 00/10] Allocation APIs
From: Danilo Krummrich <dakr@redhat.com>
To: Benno Lossin <benno.lossin@proton.me>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>, Zhi Wang <zhiw@nvidia.com>,
 rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
 Alex Gaynor <alex.gaynor@gmail.com>, Boqun Feng <boqun.feng@gmail.com>,
 Gary Guo <gary@garyguo.net>, =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?=
 <bjorn3_gh@protonmail.com>, Andreas Hindborg <a.hindborg@samsung.com>,
 Alice Ryhl <aliceryhl@google.com>, linux-kernel@vger.kernel.org,
 Wedson Almeida Filho <walmeida@microsoft.com>, ajanulgu@redhat.com,
 Andy Currid <acurrid@nvidia.com>, Neo Jia <cjia@nvidia.com>,
 John Hubbard <jhubbard@nvidia.com>
References: <Zip4dFpt8xhk7UBL@cassiopeiae>
 <74cbdaf7-360e-47e3-bda4-4661422a11ae@proton.me> <ZiqkIQTHe9apd-LW@pollux>
 <f71c4e07-9f6f-4709-a3bb-012e644c4845@proton.me>
 <Zirfyp_NiYCRQYvk@cassiopeiae>
 <71dd99fe-0d64-47cc-b367-8fdd4fcdbdca@proton.me> <ZiuCm4VtFiCfzTPI@pollux>
Content-Language: en-US
Organization: RedHat
In-Reply-To: <ZiuCm4VtFiCfzTPI@pollux>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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