lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH5fLghV4gYWMyscY2y+TwwqMW_497Sg0sj_HuzNH4nB_5u6Bg@mail.gmail.com>
Date: Thu, 12 Jun 2025 10:49:45 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Burak Emir <bqe@...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: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).

Alice

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ