[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBYC7MRfSLJI1ruC@polis>
Date: Sat, 3 May 2025 13:50:04 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Matthew Maurer <mmaurer@...gle.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/7] rust: alloc: add Vec::push_within_capacity
On Fri, May 02, 2025 at 04:25:01PM +0200, Alice Ryhl wrote:
> On Fri, May 2, 2025 at 4:07 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Fri, May 02, 2025 at 01:19:31PM +0000, Alice Ryhl wrote:
> > > This introduces a new method called `push_within_capacity` for appending
> > > to a vector without attempting to allocate if the capacity is full. Rust
> > > Binder will use this in various places to safely push to a vector while
> > > holding a spinlock.
> > >
> > > The implementation is moved to a push_within_capacity_unchecked method.
> > > This is preferred over having push() call push_within_capacity()
> > > followed by an unwrap_unchecked() for simpler unsafe.
> > >
> > > Panics in the kernel are best avoided when possible, so an error is
> > > returned if the vector does not have sufficient capacity. An error type
> > > is used rather than just returning Result<(),T> to make it more
> > > convenient for callers (i.e. they can use ? or unwrap).
> > >
> > > Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> > > + /// Appends an element to the back of the [`Vec`] instance without reallocating.
> > > + ///
> > > + /// # Safety
> > > + ///
> > > + /// The length must be less than the capacity.
> > > + pub unsafe fn push_within_capacity_unchecked(&mut self, v: T) {
> >
> > Why does this have to be public? Does binder need to call this instead
> > of just push_within_capacity()?
>
> It does not need to be public.
Gonna fix when I apply the series.
Powered by blists - more mailing lists