From: Boqun Feng <boqun.feng@gmail.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: "Daniel Almeida" <daniel.almeida@collabora.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@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>,
"Danilo Krummrich" <dakr@kernel.org>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v6] rust: kernel: add support for bits/genmask macros
Date: Sat, 14 Jun 2025 08:06:04 -0700 [thread overview]
Message-ID: <aE2P3OBo1Ufjctxy@Mac.home> (raw)
In-Reply-To: <DAMAPVAI3V8X.N8SAQD6KOO1Q@nvidia.com>
On Sat, Jun 14, 2025 at 10:38:11PM +0900, Alexandre Courbot wrote:
[...]
> > +macro_rules! impl_genmask_fn {
> > + (
> > + $ty:ty, $checked_bit:ident, $bit:ident, $genmask:ident, $genmask_checked:ident, $genmask_unbounded:ident,
> > + $(#[$genmask_ex:meta])*
> > + ) => {
> > + /// Creates a compile-time contiguous bitmask for the given range by
> > + /// validating the range at runtime.
> > + ///
> > + /// Returns [`None`] if the range is invalid, i.e.: if the start is
> > + /// greater than or equal to the end.
> > + #[inline]
> > + pub fn $genmask_checked(range: Range<u32>) -> Option<$ty> {
> > + if range.start >= range.end || range.end > <$ty>::BITS {
> > + return None;
> > + }
>
> From this check I assumed that you interpret `range` as non-inclusive,
> since `range.end == 32` is valid on u32...
>
> > + let high = $checked_bit(range.end)?;
>
> ... however IIUC `checked_bit` will return `None` here in such a case.
> Should the argument be `range.end - 1`?
>
> Your examples do seem to interpret the range as inclusive though, so
> probably the check should be `|| range.end >= <$ty>::BITS`. But that
> triggers the question, is it ok to use `Range` that way, when its
> documentation specifically states that it is bounded exclusively above?
> We could use `RangeInclusive` to match the semantics, which would
> require us to write the ranges as `0..=7`. At least it is clear that the
> upper bound is inclusive.
>
> ... or we make the methods generic against `RangeBounds` and allow both
> `Range` and `RangeInclusive` to be used. But I'm concerned that callers
> might use `0..1` thinking it is inclusive while it is not.
>
I think generic over `RangeBounds` is a good idea, and we should
.is_emtpy() or .contains() instead of comparison + boolean operation
when possible. Seems we need a function to check whether one range
contains another range, which is not available currently?
I would not be worried about callers treating `0..1` as inclusive: this
is a Rust project anyway, we need to learn the correct semantics of
expressions eventually ;-)
Regards,
Boqun
> Thoughts?
>
> > + let low = $checked_bit(range.start)?;
> > + Some((high | (high - 1)) & !(low - 1))
> > + }
> > +
> > + /// Creates a compile-time contiguous bitmask for the given range by
> > + /// validating the range at runtime.
> > + ///
> > + /// Returns `0` if the range is invalid, i.e.: if the start is greater
> > + /// than or equal to the end.
> > + #[inline]
> > + pub fn $genmask_unbounded(range: Range<u32>) -> $ty {
> > + match $genmask_checked(range) {
> > + Some(v) => v,
> > + None => 0,
> > + }
[...]
next prev parent reply other threads:[~2025-06-14 15:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 14:14 [PATCH v6] rust: kernel: add support for bits/genmask macros Daniel Almeida
2025-06-10 18:08 ` Miguel Ojeda
2025-06-10 20:52 ` Daniel Almeida
2025-06-14 13:38 ` Alexandre Courbot
2025-06-14 15:06 ` Boqun Feng [this message]
2025-06-14 15:56 ` Boqun Feng
2025-06-14 16:05 ` Boqun Feng
2025-06-18 20:58 ` Joel Fernandes
2025-06-20 13:48 ` Daniel Almeida
2025-06-20 20:47 ` Joel Fernandes
2025-06-15 12:59 ` Alexandre Courbot
2025-06-16 14:14 ` Daniel Almeida
2025-06-16 14:29 ` Boqun Feng
2025-06-16 14:42 ` Daniel Almeida
2025-06-16 14:45 ` Daniel Almeida
2025-06-16 14:52 ` Alexandre Courbot
2025-06-16 14:56 ` Daniel Almeida
2025-06-16 15:02 ` Alexandre Courbot
2025-06-16 15:02 ` Boqun Feng
2025-06-16 15:08 ` Alexandre Courbot
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=aE2P3OBo1Ufjctxy@Mac.home \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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).