[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACQBu=WiFs=6K78EuTOhe6HR39uXr8ZEKCz=MVNwKoxOV+F+iQ@mail.gmail.com>
Date: Thu, 12 Jun 2025 11:04:36 +0200
From: Burak Emir <bqe@...gle.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Yury Norov <yury.norov@...il.com>, Kees Cook <kees@...nel.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Viresh Kumar <viresh.kumar@...aro.org>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, "Gustavo A . R . Silva" <gustavoars@...nel.org>,
Carlos LLama <cmllamas@...gle.com>, Pekka Ristola <pekkarr@...tonmail.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v12 3/5] rust: add bitmap API.
On Thu, Jun 12, 2025 at 10:49 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> On Thu, Jun 12, 2025 at 10:47 AM Burak Emir <bqe@...gle.com> wrote:
> >
> > On Wed, Jun 11, 2025 at 11:58 PM Alice Ryhl <aliceryhl@...gle.com> wrote:
> > >
> > > On Wed, Jun 11, 2025 at 9:48 PM Burak Emir <bqe@...gle.com> wrote:
> > [...]
> > > > diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
> > > > new file mode 100644
> > > > index 000000000000..1fe72ca980ac
> > > > --- /dev/null
> > > > +++ b/rust/kernel/bitmap.rs
> > > > @@ -0,0 +1,582 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +// Copyright (C) 2025 Google LLC.
> > > > +
> > > > +//! Rust API for bitmap.
> > > > +//!
> > > > +//! C headers: [`include/linux/bitmap.h`](srctree/include/linux/bitmap.h).
> > > > +
> > > > +use crate::alloc::{AllocError, Flags};
> > > > +use crate::bindings;
> > > > +#[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
> > > > +use crate::pr_err;
> > > > +use core::ptr::NonNull;
> > > > +
> > > > +/// Represents a C bitmap. Wraps underlying C bitmap API.
> > > > +///
> > > > +/// # Invariants
> > > > +///
> > > > +/// Must reference a `[c_ulong]` long enough to fit `data.len()` bits.
> > > > +#[cfg_attr(CONFIG_64BIT, repr(align(8)))]
> > > > +#[cfg_attr(not(CONFIG_64BIT), repr(align(4)))]
> > > > +pub struct CBitmap {
> > > > + data: [()],
> > > > +}
> > >
> > > I wonder if we should just call this type Bitmap?
> > >
> >
> > OK. I am renaming the other type to OwnedBitmap then.
>
> Just thinking a bit more about naming ... how about calling it
> BitmapVec? Rust generally uses the terminology "Vec" to refer to
> arrays whose size is not known at compile-time, and "Array" when the
> size is known. Then, if we eventually add another type for declaring
> fixed-size bitmaps in Rust, that type can be BitmapArray (that's the
> type you'll want in a global).
It sounds good, better than OwnedBitmap.
My only hesitation is that BitmapVec does not support growing (or realloc).
On the other hand, we could support that in the future so it still makes sense.
cheers,
Burak
Powered by blists - more mailing lists