From: Danilo Krummrich <dakr@kernel.org>
To: Remo Senekowitsch <remo@buenzli.dev>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Daniel Scally" <djrscally@gmail.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Rob Herring" <robh@kernel.org>,
"Dirk Behme" <dirk.behme@de.bosch.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Saravana Kannan" <saravanak@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
devicetree@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 07/10] rust: Add arrayvec
Date: Thu, 27 Mar 2025 15:40:06 +0100 [thread overview]
Message-ID: <Z-VjRmiWDj6teoFL@cassiopeiae> (raw)
In-Reply-To: <20250326171411.590681-8-remo@buenzli.dev>
On Wed, Mar 26, 2025 at 06:13:46PM +0100, Remo Senekowitsch wrote:
> This patch is basically a proof of concept intendend to gather feedback
> about how to do this properly. Normally I would want to use the crate
> from crates.io[1], but that's not an option in the kernel. We could also
> vendor the entire source code of arrayvec. I'm not sure if people will
> be happy with that.
Do we really need this? The only user in this series I could spot was
property_get_reference_args(). And I think that with a proper abstraction of
struct fwnode_reference_args we could avoid to copy memory at all.
If it turns out we actually need something like this, I'd prefer to move it to
rust/kernel/alloc/ and see if it's worth to derive a common trait that maybe can
share a few things between ArrayVec and Vec.
>
> [1] https://crates.io/crates/arrayvec
>
> Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
> ---
> rust/kernel/arrayvec.rs | 81 +++++++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 1 +
> 2 files changed, 82 insertions(+)
> create mode 100644 rust/kernel/arrayvec.rs
>
> diff --git a/rust/kernel/arrayvec.rs b/rust/kernel/arrayvec.rs
> new file mode 100644
> index 000000000..041e7dcce
> --- /dev/null
> +++ b/rust/kernel/arrayvec.rs
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Provides [ArrayVec], a stack-allocated vector with static capacity.
> +
> +use core::mem::MaybeUninit;
> +
> +/// A stack-allocated vector with statically fixed capacity.
> +///
> +/// This can be useful to avoid heap allocation and still ensure safety where a
> +/// small but dynamic number of elements is needed.
> +///
> +/// For example, consider a function that returns a variable number of values,
> +/// but no more than 8. In C, one might achieve this by passing a pointer to
> +/// a stack-allocated array as an out-parameter and making the function return
> +/// the actual number of elements. This is not safe, because nothing prevents
> +/// the caller from reading elements from the array that weren't actually
> +/// initialized by the function. `ArrayVec` solves this problem, users are
> +/// prevented from accessing uninitialized elements.
> +///
> +/// This basically exists already (in a much more mature form) on crates.io:
> +/// <https://crates.io/crates/arrayvec>
> +#[derive(Debug)]
> +pub struct ArrayVec<const N: usize, T> {
> + array: [core::mem::MaybeUninit<T>; N],
> + len: usize,
> +}
> +
> +impl<const N: usize, T> ArrayVec<N, T> {
> + /// Adds a new element to the end of the vector.
> + ///
> + /// # Panics
> + ///
> + /// Panics if the vector is already full.
> + pub fn push(&mut self, elem: T) {
> + if self.len == N {
> + panic!("OOM")
Please do not panic, this should return a Result instead.
next prev parent reply other threads:[~2025-03-27 14:40 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 17:13 [PATCH 0/10] More Rust bindings for device property reads Remo Senekowitsch
2025-03-26 17:13 ` [PATCH 01/10] rust: Move property_present to property.rs Remo Senekowitsch
2025-03-26 20:51 ` Rob Herring
2025-03-26 22:41 ` Rob Herring
2025-04-04 12:48 ` Remo Senekowitsch
2025-03-26 20:58 ` Andrew Ballance
2025-03-27 8:37 ` Andy Shevchenko
2025-03-27 13:55 ` Rob Herring
2025-03-27 17:49 ` Andy Shevchenko
2025-03-26 17:13 ` [PATCH 02/10] rust: Add an Integer trait Remo Senekowitsch
2025-03-26 20:00 ` Rob Herring
2025-03-26 17:13 ` [PATCH 03/10] device property: Add fwnode_property_read_int_array() Remo Senekowitsch
2025-03-27 8:41 ` Andy Shevchenko
2025-04-02 16:04 ` Remo Senekowitsch
2025-04-03 13:28 ` Andy Shevchenko
2025-04-03 16:08 ` Rob Herring
2025-04-03 16:15 ` Remo Senekowitsch
2025-04-03 17:04 ` Remo Senekowitsch
2025-04-03 17:22 ` Rob Herring
2025-04-04 12:29 ` Remo Senekowitsch
2025-04-03 16:04 ` Rob Herring
2025-04-03 16:15 ` Andy Shevchenko
2025-04-03 16:36 ` Rob Herring
2025-04-03 17:54 ` Andy Shevchenko
2025-04-03 18:48 ` Rob Herring
2025-04-03 20:36 ` Miguel Ojeda
2025-04-04 11:00 ` Andy Shevchenko
2025-04-04 14:12 ` Rob Herring
2025-04-04 16:35 ` Andy Shevchenko
2025-03-26 17:13 ` [PATCH 04/10] rust: Add bindings for reading device properties Remo Senekowitsch
2025-03-26 21:27 ` Rob Herring
2025-04-02 16:28 ` Remo Senekowitsch
2025-03-26 17:13 ` [PATCH 05/10] rust: Read properties via single generic method Remo Senekowitsch
2025-03-26 21:33 ` Rob Herring
2025-03-26 17:13 ` [PATCH 06/10] rust: property: Add child accessor and iterator Remo Senekowitsch
2025-03-26 21:04 ` Andrew Ballance
2025-03-26 21:40 ` Rob Herring
2025-03-26 17:13 ` [PATCH 07/10] rust: Add arrayvec Remo Senekowitsch
2025-03-26 21:06 ` Andrew Ballance
2025-03-27 14:40 ` Danilo Krummrich [this message]
2025-03-26 17:13 ` [PATCH 08/10] rust: property: Add property_get_reference_args Remo Senekowitsch
2025-03-26 21:07 ` Andrew Ballance
2025-03-26 21:25 ` Miguel Ojeda
2025-03-26 21:45 ` Remo Senekowitsch
2025-03-27 14:32 ` Danilo Krummrich
2025-03-26 17:13 ` [PATCH 09/10] rust: property: Add PropertyGuard Remo Senekowitsch
2025-03-26 21:10 ` Andrew Ballance
2025-03-26 22:25 ` Rob Herring
2025-03-26 17:13 ` [PATCH 10/10] samples: rust: platform: Add property read examples Remo Senekowitsch
2025-03-26 22:01 ` Rob Herring
2025-03-26 22:23 ` Remo Senekowitsch
2025-03-27 0:02 ` Rob Herring
2025-03-27 10:28 ` Danilo Krummrich
2025-03-26 20:54 ` [PATCH 0/10] More Rust bindings for device property reads Andrew Ballance
2025-03-27 8:42 ` Andy Shevchenko
2025-04-14 15:26 ` [PATCH v2 0/5] " Remo Senekowitsch
2025-04-14 15:26 ` [PATCH v2 1/5] rust: Move property_present to separate file Remo Senekowitsch
2025-04-14 16:00 ` Danilo Krummrich
2025-04-14 16:40 ` Remo Senekowitsch
2025-04-14 18:00 ` Danilo Krummrich
2025-04-15 11:17 ` Remo Senekowitsch
2025-04-14 15:26 ` [PATCH v2 2/5] rust: Add bindings for reading device properties Remo Senekowitsch
2025-04-14 17:44 ` Danilo Krummrich
2025-04-14 18:05 ` Danilo Krummrich
2025-04-14 23:55 ` Remo Senekowitsch
2025-04-15 9:48 ` Danilo Krummrich
2025-04-15 11:11 ` Remo Senekowitsch
2025-04-15 12:46 ` Rob Herring
2025-04-15 13:11 ` Danilo Krummrich
2025-04-15 14:47 ` Remo Senekowitsch
2025-04-16 18:28 ` Gary Guo
2025-04-23 12:29 ` Dirk Behme
2025-04-24 11:25 ` Remo Senekowitsch
2025-04-23 12:34 ` Dirk Behme
2025-04-14 15:26 ` [PATCH v2 3/5] rust: property: Add child accessor and iterator Remo Senekowitsch
2025-04-14 16:09 ` Danilo Krummrich
2025-04-14 15:26 ` [PATCH v2 4/5] rust: property: Add property_get_reference_args Remo Senekowitsch
2025-04-14 15:26 ` [PATCH v2 5/5] samples: rust: platform: Add property read examples Remo Senekowitsch
2025-04-23 12:39 ` Dirk Behme
2025-04-24 5:47 ` Dirk Behme
2025-04-14 15:38 ` [PATCH v2 0/5] More Rust bindings for device property reads Miguel Ojeda
2025-04-14 16:07 ` Remo Senekowitsch
2025-04-14 16:44 ` Miguel Ojeda
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=Z-VjRmiWDj6teoFL@cassiopeiae \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=djrscally@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=remo@buenzli.dev \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@google.com \
--cc=tmgross@umich.edu \
/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.