[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <D8LFO0LQOPQJ.30AC77E0BOH3@proton.me>
Date: Thu, 20 Mar 2025 22:06:18 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Alice Ryhl <aliceryhl@...gle.com>, Danilo Krummrich <dakr@...nel.org>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] rust: alloc: add Vec::drain_all
On Thu Mar 20, 2025 at 2:52 PM CET, Alice Ryhl wrote:
> This is like the stdlib method drain, except that it's hard-coded to use
> the entire vector's range. Rust Binder uses it in the range allocator to
> take ownership of everything in a vector in a case where reusing the
> vector is desirable.
Is the reason for not implementing `drain` complexity?
> Implementing `DrainAll` in terms of `slice::IterMut` lets us reuse some
> nice optimizations in core for the case where T is a ZST.
>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
The code is good, but I'd like to know the answer to the above question
before giving my RB.
> ---
> rust/kernel/alloc/kvec.rs | 57 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
> index df930ff0d0b85b8b03c9b7932a2b31dfb62612ed..303198509885f5e24b74da5a92382b518de3e1c0 100644
> --- a/rust/kernel/alloc/kvec.rs
> +++ b/rust/kernel/alloc/kvec.rs
> @@ -564,6 +564,30 @@ pub fn truncate(&mut self, len: usize) {
> // len, therefore we have exclusive access to [`new_len`, `old_len`)
> unsafe { ptr::drop_in_place(ptr) };
> }
> +
> + /// Takes ownership of all items in this vector without consuming the allocation.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// let mut v = kernel::kvec![0, 1, 2, 3]?;
> + ///
> + /// for (i, j) in v.drain_all().enumerate() {
> + /// assert_eq!(i, j);
> + /// }
> + ///
> + /// assert!(v.capacity() >= 4);
> + /// ```
> + pub fn drain_all(&mut self) -> DrainAll<'_, T> {
> + let len = self.len();
> + // INVARIANT: The first 0 elements are valid.
> + self.len = 0;
Why not `set_len`?
> + // INVARIANT: The first `len` elements of the spare capacity are valid values, and as we
> + // just set the length to zero, we may transfer ownership to the `DrainAll` object.
> + DrainAll {
> + elements: self.spare_capacity_mut()[..len].iter_mut(),
> + }
> + }
> }
>
> impl<T: Clone, A: Allocator> Vec<T, A> {
> @@ -1049,3 +1073,36 @@ fn into_iter(self) -> Self::IntoIter {
> }
> }
> }
> +
> +/// An iterator that owns all items in a vector, but does not own its allocation.
> +///
> +/// # Invariants
> +///
> +/// Every `&mut MaybeUninit<T>` returned by the iterator contains a valid `T` owned by this
> +/// `DrainAll`.
> +pub struct DrainAll<'vec, T> {
> + elements: slice::IterMut<'vec, MaybeUninit<T>>,
> +}
> +
> +impl<'vec, T> Iterator for DrainAll<'vec, T> {
> + type Item = T;
> +
> + fn next(&mut self) -> Option<T> {
> + let elem = self.elements.next()?;
> + // SAFETY: By the type invariants, we may take ownership of the value in this
> + // `MaybeUninit<T>`.
> + Some(unsafe { elem.assume_init_read() })
> + }
> +
> + fn size_hint(&self) -> (usize, Option<usize>) {
> + self.elements.size_hint()
> + }
> +}
> +
> +impl<'vec, T> Drop for DrainAll<'vec, T> {
> + fn drop(&mut self) {
> + if core::mem::needs_drop::<T>() {
This is neat!
---
Cheers,
Benno
> + while self.next().is_some() {}
> + }
> + }
> +}
Powered by blists - more mailing lists