From: "Danilo Krummrich" <dakr@kernel.org>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Gary Guo" <gary@garyguo.net>, "Lorenzo Stoakes" <ljs@kernel.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Uladzislau Rezki" <urezki@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH 1/6] rust: alloc: add Vec::push_init
Date: Wed, 19 Aug 2026 12:49:12 +0200 [thread overview]
Message-ID: <DKSV1A4SL7PX.2EM92OHEQHA9@kernel.org> (raw)
In-Reply-To: <DKSR2WF91FL0.78WHY1E7WIX9@nvidia.com>
On Wed Aug 19, 2026 at 9:43 AM CEST, Eliot Courtney wrote:
> There's also some locations in other code that could use a VecView directly
> instead of taking a &mut Vec etc. Having a Vec-like thing that's guaranteed not
> to allocate also sounds potentially useful to me w.r.t. safety for contexts
> where you can't allocate/sleep.
Allocation in atomic context is still possible as long as we avoid memory
reclaim, e.g. with GFP_ATOMIC. However, this should generally be avoided, plus
there are also cases in non-atomic context where we can't have memory reclaim,
such as the DMA fence signaling critical section. So, I think this can a be a
useful API.
> If you think this approach is ok I can send it as a separate series. Codegen
> appears fine practically speaking AFAICT.
I think this is orthogonal from what you need in this series; also remember that
we need a user with real need for an API before we can introduce it.
It might have a use-case in DRM Jobqueue, where it could be used to handle
pre-allocation for ring buffer slots of jobs before entering the DMA fence
signaling critical section. However, I'm not convinced that Vec or a VecDeque
like type is the best solution for DRM Jobqueue in the first place.
> pub type Zero = ();
> pub type Succ<N> = (N,);
> pub type One = Succ<Zero>;
> pub type Two = Succ<One>;
That can produce annoying error messages, but without const generic expr it is
what it is.
> // Infallible (except for Init) push. `Zero` spare VecView has the fallible version.
> impl<'a, T, N: Count> VecView<'a, T, Succ<N>> {
> pub fn push<E>(self, init: impl Init<T, E>) -> Result<VecView<'a, T, N>, E> {
We still want push() taking impl Init<T> and try_push() taking impl Init<T, E>,
so we get rid of the Result for impl Init<T, Infallible>.
> // Fallible but not allocating ops (can run out of space).
> impl<'a, T> VecView<'a, T> {
> pub fn push<I: Init<T, E>, E>(&mut self, init: I) -> Result<(), PushInitError<I, E>> {
> if *self.len == self.cap {
> return Err(PushInitError::Full(init));
> }
>
> unsafe { init.__init(self.buf.as_ptr().add(*self.len)) }.map_err(PushInitError::Init)?;
> *self.len += 1;
>
> Ok(())
> }
>
> // Bodies as in the current KVec implementations.
We'd still need forwarding functions on Vec, so we don't force users to go
through view().
> pub fn pop(&mut self) -> Option<T> { ... }
> pub fn insert(&mut self, index: usize, element: T) -> Result<(), InsertError<T>> { ... }
> pub fn remove(&mut self, i: usize) -> Result<T, RemoveError> { ... }
> pub fn truncate(&mut self, len: usize) { ... }
> pub fn retain(&mut self, f: impl FnMut(&mut T) -> bool) { ... }
> pub fn drain_all(self) -> DrainAll<'a, T> { ... }
> pub fn len(&self) -> usize { ... }
> pub fn as_slice(&self) -> &[T] { ... }
> pub fn as_mut_slice(&mut self) -> &mut [T] { ... }
> pub fn spare_capacity(&self) -> usize { ... }
> pub fn spare_capacity_mut(&mut self) -> &mut [MaybeUninit<T>] { ... }
> pub unsafe fn commit(&mut self, additional: usize) { ... }
> }
next prev parent reply other threads:[~2026-08-19 10:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 12:56 [PATCH 0/6] gpu: nova-core: add NVKV codec Eliot Courtney
2026-08-17 12:56 ` [PATCH 1/6] rust: alloc: add Vec::push_init Eliot Courtney
2026-08-17 14:02 ` Gary Guo
2026-08-19 7:43 ` Eliot Courtney
2026-08-19 10:49 ` Danilo Krummrich [this message]
2026-08-19 11:23 ` Danilo Krummrich
2026-08-19 12:08 ` Gary Guo
2026-08-19 12:14 ` Gary Guo
2026-08-17 12:56 ` [PATCH 2/6] gpu: nova-core: add NVKV encoder Eliot Courtney
2026-08-17 13:06 ` sashiko-bot
2026-08-17 12:56 ` [PATCH 3/6] gpu: nova-core: add NVKV decoder Eliot Courtney
2026-08-17 13:06 ` sashiko-bot
2026-08-17 12:56 ` [PATCH 4/6] gpu: nova-core: add NVKV typed encoding Eliot Courtney
2026-08-17 12:56 ` [PATCH 5/6] gpu: nova-core: add NVKV typed decoding Eliot Courtney
2026-08-17 12:56 ` [PATCH 6/6] gpu: nova-core: add NVKV GSP_INIT schemas Eliot Courtney
2026-08-17 13:06 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DKSV1A4SL7PX.2EM92OHEQHA9@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel-bounces@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=urezki@gmail.com \
--cc=vbabka@kernel.org \
--cc=work@onurozkan.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.