All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Burak Emir" <bqe@google.com>,
	"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>,
	"Trevor Gross" <tmgross@umich.edu>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: add bindings and API for bitmap.h and bitops.h.
Date: Mon, 3 Mar 2025 10:03:52 -0500	[thread overview]
Message-ID: <Z8XE2H3vGDNiOra7@thinkpad> (raw)
In-Reply-To: <CAH5fLgiQkPpMUV0Bvmwd5zUsHy=GHLdoVFjRuAPxpWCbBiD2Jw@mail.gmail.com>

On Mon, Mar 03, 2025 at 02:01:44PM +0100, Alice Ryhl wrote:
> > > +void rust_helper_bitmap_copy(unsigned long *dst, const unsigned long *src, unsigned int nbits)
> > > +{
> > > +       bitmap_copy(dst, src, nbits);
> > > +}
> >
> > I was about to say that this could just be a memcpy, but ...
> >
> > > +    /// Copy up to `nbits` bits from this bitmap into another.
> > > +    ///
> > > +    /// # Panics
> > > +    ///
> > > +    /// Panics if `nbits` is too large for this bitmap or destination.
> > > +    #[inline]
> > > +    pub fn bitmap_copy(&self, dst: &mut Bitmap, nbits: usize) {
> > > +        if self.nbits < nbits {
> > > +            panic_not_in_bounds_le("nbits", self.nbits, nbits);
> > > +        }
> > > +        if dst.nbits < nbits {
> > > +            panic_not_in_bounds_le("nbits", dst.nbits, nbits);
> > > +        }
> > > +        // SAFETY: nbits == 0 is supported and access to `self` and `dst` is within bounds.
> > > +        unsafe { bindings::bitmap_copy(dst.as_mut_ptr(), self.ptr.as_ptr(), nbits as u32) };
> > > +    }
> >
> > ... then I realized that we're probably not using it correctly. I
> > would expect this to modify the first `nbits` bits in `dst`, leaving
> > any remaining bits unmodified. However, if nbits is not divisible by
> > BITS_PER_LONG it might modify some bits it shouldn't.
> >
> > That said, Binder needs this only in the case where the sizes are
> > equal. Perhaps we could rename this to `copy_from_bitmap` with this
> > signature:
> > fn copy_from_bitmap(&mut self, src: Bitmap)
> 
> Sorry I meant src: &Bitmap here.

Yes, you're right. bitmap_copy() copies the whole bitmap. So if your
Bitmap already has size, you don't need to pass it explicitly.
 
> Also, we could rewrite it to just call memcpy rather than go through
> bitmap_copy. Though that requires us to have a Rust version of
> bitmap_size, which I think it makes sense to avoid using a Rust helper
> for.

No, you couldn't. I don't want rust bindings to diverge from the main
kernel. So the rule is simple: if inline wrapper exists only for the
small_const_nbits() optimization - go ahead and use the outlined
underscored version. If the wrapper does something else - no matter
what - it should be wrapped.

> We could reimplement it by first computing the number of longs and
> then computing the number of bytes
> 
> const fn bitmap_size(nbits: usize) -> usize {
>     nbits.div_ceil(c_ulong::BITS) * size_of::<c_ulong>()
> }
> 
> Thoughts?
> 
> Alice

      reply	other threads:[~2025-03-03 15:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 11:40 [PATCH v2] rust: add bindings and API for bitmap.h and bitops.h Burak Emir
2025-03-03 12:48 ` Alice Ryhl
2025-03-03 13:01   ` Alice Ryhl
2025-03-03 15:03     ` Yury Norov [this message]

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=Z8XE2H3vGDNiOra7@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.