All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Burak Emir <bqe@google.com>
Cc: "Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"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>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/4] rust: adds Bitmap API, ID pool and bindings
Date: Fri, 21 Mar 2025 10:31:43 -0400	[thread overview]
Message-ID: <Z914T_oYHvV_Zk74@thinkpad> (raw)
In-Reply-To: <20250321111535.3740332-1-bqe@google.com>

On Fri, Mar 21, 2025 at 11:15:28AM +0000, Burak Emir wrote:
> This series adds a Rust bitmap API for porting the approach from 
> commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup")
> to Rust. The functionality in dbitmap.h makes use of bitmap and bitops.
> 
> The Rust bitmap API provides a safe abstraction to underlying bitmap
> and bitops operations. For now, only includes method necessary for 
> dbitmap.h, more can be added later. We perform bounds checks for 
> hardening, violations are programmer errors that result in panics.
> 
> This version includes an optimization to represent the bitmap inline,
> as suggested by Yury.

We have a tag for it:

Suggested-by: Yury Norov <yury.norov@gmail.com>
 
> The Rust equivalent of dbitmap.h is included as id_pool.rs, which is
> tightly coupled to the bitmap API. Includes an example of usage
> that requires releasing a spinlock, as expected in Binder driver.

I don't think it's worth to refer the existing dbitmap.h, because:

1. It's buggy;
2. You limit yourself with committing to provide an 'equivalent' API.
3. If you want to bring the existing dbitmaps.h, you'd just bring
   bindings for them, not a re-implementation.

Can you just say that you're adding dynamic bit arrays in rust?

> This is v5 of a patch introducing Rust bitmap API [v4]. Thanks
> for all the helpful comments, this series has improved significantly
> as a result of your work.
> 
> Changes v4 --> v5: (suggested by Yury and Alice)
> - rebased on next-20250318
> - split MAINTAINERS changes
> - no dependencies on [1] and [2] anymore - Viresh,
>   please do add a separate section if you want to maintain cpumask.rs
>   separately.
> - imports atomic and non-atomic variants, introduces a naming convention
>   set_bit and set_bit_atomic on the Rust side.
> - changed naming and comments. Keeping `new`.
> - change dynamic_id_pool to id_pool
> - represent bitmap inline when possible
> - add some more tests
> - add bqe@google.com as M: for the Rust abstractions

Instead of 'bqe@google.com' just say: myself.

Thanks,
Yury

  parent reply	other threads:[~2025-03-21 14:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 11:15 [PATCH v5 0/4] rust: adds Bitmap API, ID pool and bindings Burak Emir
2025-03-21 11:15 ` [PATCH v5 1/4] rust: add bindings for bitmap.h Burak Emir
2025-03-21 11:15 ` [PATCH v5 2/4] rust: add bindings for bitops.h Burak Emir
2025-03-21 16:04   ` Yury Norov
2025-03-21 11:15 ` [PATCH v5 3/4] rust: add bitmap API Burak Emir
2025-03-21 16:04   ` Yury Norov
2025-03-21 18:49     ` Miguel Ojeda
2025-03-27 16:18       ` Burak Emir
2025-03-28  8:51       ` David Gow
2025-03-28  8:51         ` David Gow
2025-03-28  9:06         ` Miguel Ojeda
2025-04-23 12:04           ` Burak Emir
2025-03-27 14:30     ` Burak Emir
2025-03-21 11:15 ` [PATCH v5 4/4] rust: add dynamic ID pool abstraction for bitmap Burak Emir
2025-03-21 16:34   ` Yury Norov
2025-03-27 14:18     ` Burak Emir
2025-03-21 14:31 ` Yury Norov [this message]
2025-03-27 11:42   ` [PATCH v5 0/4] rust: adds Bitmap API, ID pool and bindings Burak Emir

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=Z914T_oYHvV_Zk74@thinkpad \
    --to=yury.norov@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bqe@google.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=viresh.kumar@linaro.org \
    /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.