[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D29BB87C-356E-4885-8308-456028AE3B6F@collabora.com>
Date: Mon, 16 Jun 2025 11:42:43 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...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>,
Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>,
linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v6] rust: kernel: add support for bits/genmask macros
Hi Boqun,
>
> We should tell/educate people to do the right thing, if a..b is not
> inclusive in Rust, then we should treat them as non-inclusive in Rust
> kernel code. Otherwise you create confusion for no reason. My assumption
> is that most people will ask "what's the right way to do this" first
> instead of replicating the old way.
>
> Regards,
> Boqun
>
This is just my opinion, of course:
I _hardly_ believe this will be the case. When people see genmask and two
numbers, they expect the range to be inclusive, full stop (at least IMHO). That's how it has
worked for decades, so it’s only natural to expect this behavior to transfer over.
However, I do understand and agree with your point, and I will change the
implementation here to comply. Perhaps we can use some markdown to alert users?
— Daniel
Powered by blists - more mailing lists