From: Alice Ryhl <aliceryhl@google.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: "Tamir Duberstein" <tamird@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Christian Brauner" <brauner@kernel.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Burak Emir" <bqe@google.com>, "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/6] rust: bitmap: add MAX_LEN and NO_ALLOC_MAX_LEN constants
Date: Mon, 10 Nov 2025 15:11:35 +0000 [thread overview]
Message-ID: <aRIAp3LHs0NsEKvL@google.com> (raw)
In-Reply-To: <aRH-ScufjvGYPx5W@yury>
On Mon, Nov 10, 2025 at 10:01:29AM -0500, Yury Norov wrote:
> On Mon, Nov 10, 2025 at 02:20:17PM +0000, Alice Ryhl wrote:
> > On Mon, Nov 10, 2025 at 08:59:36AM -0500, Tamir Duberstein wrote:
> > > On Mon, Nov 10, 2025 at 8:06 AM Alice Ryhl <aliceryhl@google.com> wrote:
> > > >
> > > > To avoid hard-coding these values in drivers, define constants for them
> > > > that drivers can reference.
> > > >
> > > > Acked-by: Danilo Krummrich <dakr@kernel.org>
> > > > Reviewed-by: Burak Emir <bqe@google.com>
> > > > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > > > ---
> > > > rust/kernel/bitmap.rs | 16 +++++++++++-----
> > > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
> > > > index aa8fc7bf06fc99865ae755d8694e4bec3dc8e7f0..15fa23b45054b9272415fcc000e3e3b52c74d7c1 100644
> > > > --- a/rust/kernel/bitmap.rs
> > > > +++ b/rust/kernel/bitmap.rs
> > > > @@ -149,14 +149,14 @@ macro_rules! bitmap_assert_return {
> > > > ///
> > > > /// # Invariants
> > > > ///
> > > > -/// * `nbits` is `<= i32::MAX` and never changes.
> > > > +/// * `nbits` is `<= MAX_LEN`.
> > > > /// * if `nbits <= bindings::BITS_PER_LONG`, then `repr` is a `usize`.
> > >
> > > Should this and other references to bindings::BITS_PER_LONG be
> > > `NO_ALLOC_MAX_LEN` instead?
> >
> > Ah yeah it probably makes sense to update this in a bunch of places.
>
> Yes, please.
>
> NO_ALLOC sounds a bit weird in exported API. Maybe NBITS_INPLACE
> or similar?
Ah, good point. We started using the "inplace" wording in other places,
so lets also do so here.
> Also, at this point we're really close to:
>
> pub const NBITS_INPLACE: usize = CONFIG_NBITS_INPLACE;
>
> union BitmapRepr {
> bitmap: [usize, BITS_TO_LONGS(NBITS_INPLACE)]
> ptr: NonNull<usize>,
> }
>
> That would be a very useful addition for some particular scenarios,
> I believe. Even if you don't want to make it configurable, let's
> keep this option in mind?
Actually, one option here is to define BitmapVec like this:
pub struct BitmapVec<const INPLACE_LEN: usize = 1> {
repr: BitmapRepr<INPLACE_LEN>,
nbits: usize,
}
union BitmapRepr<const INPLACE_LEN: usize> {
bitmap: [usize; INPLACE_LEN],
ptr: NonNull<usize>,
}
This way, the driver can specify this by saying: BitmapVec<4> for a
BitmapVec where the inline capacity is 4 longs.
And if Binder wanted to make that configurable, Binder could define a
constant based on a Binder specific CONFIG_* that controls what value
Binder passes.
Since I wrote `= 1` in the struct, you may also write BitmapVec without
specifying any number and get the default.
It may be possible to specify the number in bits rather than longs too,
but then we have to decide what to do if it's not divisible by
BITS_PER_LONG.
(But in the case of Rust Binder, the value we want is one long worth of
bits.)
Alice
next prev parent reply other threads:[~2025-11-10 15:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 13:05 [PATCH v4 0/6] Use Rust Bitmap from Rust Binder driver Alice Ryhl
2025-11-10 13:05 ` [PATCH v4 1/6] rust: bitmap: add MAX_LEN and NO_ALLOC_MAX_LEN constants Alice Ryhl
2025-11-10 13:59 ` Tamir Duberstein
2025-11-10 14:20 ` Alice Ryhl
2025-11-10 15:01 ` Yury Norov
2025-11-10 15:09 ` Yury Norov
2025-11-10 15:11 ` Alice Ryhl [this message]
2025-11-10 15:39 ` Yury Norov
2025-11-12 12:49 ` Alice Ryhl
2025-11-10 13:05 ` [PATCH v4 2/6] rust: bitmap: add BitmapVec::new_inline() Alice Ryhl
2025-11-10 13:05 ` [PATCH v4 3/6] rust: bitmap: rename IdPool::new to with_capacity Alice Ryhl
2025-11-10 14:12 ` Burak Emir
2025-11-10 13:05 ` [PATCH v4 4/6] rust: id_pool: do not supply starting capacity Alice Ryhl
2025-11-10 13:05 ` [PATCH v4 5/6] rust: id_pool: do not immediately acquire new ids Alice Ryhl
2025-11-10 13:05 ` [PATCH v4 6/6] rust_binder: use bitmap for allocation of handles Alice Ryhl
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=aRIAp3LHs0NsEKvL@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=arve@android.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bqe@google.com \
--cc=brauner@kernel.org \
--cc=cmllamas@google.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maco@android.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tamird@gmail.com \
--cc=tkjos@android.com \
--cc=tmgross@umich.edu \
--cc=yury.norov@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).