Received-SPF: pass (google.com: domain of linux-kernel+bounces-165785-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240328013603.206764-1-wedsonaf@gmail.com> <20240408094738.00005e59.zhiw@nvidia.com>
In-Reply-To: <20240408094738.00005e59.zhiw@nvidia.com>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Thu, 2 May 2024 00:06:57 +0200
Message-ID: <CANiq72nrMpg_dk4eM2Ve+aOi7QF4U-SCvLpx9PMD6o=6sdzOYQ@mail.gmail.com>
Subject: Re: [PATCH v3 00/10] Allocation APIs
To: Zhi Wang <zhiw@nvidia.com>
Cc: Wedson Almeida Filho <wedsonaf@gmail.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>, 
	Benno Lossin <benno.lossin@proton.me>, Andreas Hindborg <a.hindborg@samsung.com>, 
	Alice Ryhl <aliceryhl@google.com>, linux-kernel@vger.kernel.org, 
	Wedson Almeida Filho <walmeida@microsoft.com>, John Hubbard <jhubbard@nvidia.com>, Neo Jia <cjia@nvidia.com>, 
	Andy Currid <acurrid@nvidia.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 8, 2024 at 8:48=E2=80=AFAM Zhi Wang <zhiw@nvidia.com> wrote:
>
> IMO, It seems the allocation flag here means GFP flags according to
> Patch 5 and I understand the benefit of introducing the flags.
>
> I am interested in the future plan. With this change, will Vec and Box
> stick to kernel memory application APIs with GFP flags in the future?
> e.g. GUP, kmalloc, those mostly allocates continuous memory for small
> objects. Is that the future for Vec and Box in kernel?
>
> Is there any plan for having vmalloc() in rust kernel? Currently, if I
> push a large object into a Vec, kernel MM will complain for sure. And
> literally Vec/Box themselves don't imply to the user that they allocate
> memory with limitations.
>
> Kernel uses different MM alloc APIs for different usages. For rust,
> should we have a different kind of "Vec/Box" or having a Vec/Box with
> different set of allocation flags that covers both GFP MM APIs and
> vmalloc()? I am curious about the plan.

Sorry Zhi, Danilo brought this message to my attention today (thanks!).

We have been trying to find the best way forward to support fallible
allocations, per-call-site flags, other kernel allocators and so on
for a long time, including discussions with upstream Rust.

At this point, after these years, I think the ideal path is to try our
best to avoid re-enabling `allocator_api` and to have perhaps our own
custom APIs/types as needed (possibly several depending on the use
case) -- please also see my reply at
https://lore.kernel.org/rust-for-linux/CANiq72=3D0BNw-KiURBjosLqfuUEPpjZPbR=
g1XMFZyobOzBt7aMA@mail.gmail.com/

Regarding this patch series, we mainly wanted to make progress on
(finally) allowing at least to use the GFP flags and also,
importantly, dropping `alloc` since we want to start supporting
several compiler versions soon.

Thank you for your feedback on this. It would be nice to hear what you
think about Danilo's approach in the other series and other possible
approaches that may not rely on `allocator_api`.

Cheers,
Miguel