From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Yury Norov" <yury.norov@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev
Subject: Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro
Date: Wed, 26 Aug 2026 20:16:02 +0900 [thread overview]
Message-ID: <DKYTZNAX6ON6.1K1372FFAQOF7@nvidia.com> (raw)
In-Reply-To: <DKXUBFRQ9JUS.29G1A4GBOMOF2@nvidia.com>
On Tue Aug 25, 2026 at 4:18 PM JST, Eliot Courtney wrote:
> On Tue Aug 25, 2026 at 11:44 AM JST, Alexandre Courbot wrote:
>> The casts module features a series of const converters (e.g.
>> `u32_into_u16`) that narrow the type of a const expression provided that
>> its value can be proven to fit into the destination type at
>> compile-time.
>>
>> These functions are numerous (9 of them), generated by a macro and thus
>> not easily discoverable, and cumbersome to use as they require a
>> turbofish and const expression between `{` and `}` braces.
>>
>> Replace them all by a single `const_as!` macro that expands to a const
>> block verifying the lossless nature of the conversion at compile-time.
>> This turns e.g.:
>>
>> const DMA_LEN: u32 = casts::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>>
>> into
>>
>> const DMA_LEN: u32 = casts::const_as!(MEM_BLOCK_ALIGNMENT => u32);
>>
>> This makes things easier to read and understand, while shifting the
>> burden of checking the conversion's validity from reviewers (via a CAST
>> comment) to the compiler.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> rust/kernel/num/casts.rs | 129 +++++++++++++++++++++++++++++------------------
>> 1 file changed, 79 insertions(+), 50 deletions(-)
>>
>> diff --git a/rust/kernel/num/casts.rs b/rust/kernel/num/casts.rs
>> index 7e6c7dec747d..a4a18a6f2ba8 100644
>> --- a/rust/kernel/num/casts.rs
>> +++ b/rust/kernel/num/casts.rs
>> @@ -20,10 +20,8 @@
>> //! - Two extension traits, [`FromSafeCast`] and [`IntoSafeCast`], providing conversion methods
>> //! similar to [`From`] and [`Into`] for conversions that are safe to perform in the kernel, but
>> //! not supported by the standard library.
>> -//! - Another series of const functions (e.g. [`u64_into_u8`]) supporting the conversion of a const
>> -//! value from a larger type into a smaller one, provided the value fits into the destination
>> -//! type. This is useful if a constant is defined as a larger type, but needs to be used as a
>> -//! smaller one.
>> +//! - A [`const_as!`] macro, losslessly casting a constant expression between any two integer
>> +//! types, with conversions that would alter the value reported as build errors.
>> //! - An [`arch`] sub-module, defining more conversion functions that are only guaranteed to be
>> //! lossless for a given pointer size. These can only be used in code that is specific to a
>> //! given pointer size.
>
> Can we add guidance somewhere in this file on when to use const_as! vs
> when to use the u8_as_usize etc ones, when both could work? e.g. use
> const_as! if you can, otherwise use the function version, or, use the
> function version if it's sufficient (types alone are enough to prove)
> otherwise use the macro.
Yes, that's a very good idea and the use we are currently doing in Nova
is also not consistent. Basically I think that the priority should be,
in order of preference:
- stdlib's `From`,
- `FromSafeCast`/`IntoSafeCast` (for non-const contexts)
- `const_as!` (for constant expressions including narrowing)
- `*_as_*` (for const fns with a runtime value)
>
> [...]
>> +#[macro_export]
>> +#[doc(hidden)]
>> +macro_rules! const_as {
>> + ($v:expr => $into:ty) => {
>> + const {
>> + #[allow(unused_comparisons, unused_assignments, clippy::as_underscore)]
>> + {
>> + let v = $v;
>> + let r = v as $into;
>> + // Pin `back` to `v`'s type so `as _` casts back to the source type.
>> + let mut back = v;
>> + back = r as _;
>>
>> - N as $into
>> + ::core::assert!(
>> + back == v && (v < 0) == (r < 0),
>> + "value does not fit into the target type"
>> + );
>
> What about giving some text on what doesn't fit where? e.g.
> ::core::concat!("`", ::core::stringify!($v), "` does not fit into `", ::core::stringify!($into), "`")
Will do.
next prev parent reply other threads:[~2026-08-26 11:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 2:44 [PATCH 0/2] rust: num: casts: replace const type narrowing methods with a macro Alexandre Courbot
2026-08-25 2:44 ` [PATCH 1/2] " Alexandre Courbot
2026-08-25 7:18 ` Eliot Courtney
2026-08-26 11:16 ` Alexandre Courbot [this message]
2026-08-25 8:25 ` Miguel Ojeda
2026-08-25 12:01 ` Gary Guo
2026-08-25 14:26 ` Alexandre Courbot
2026-08-25 14:39 ` Gary Guo
2026-08-26 11:00 ` Alexandre Courbot
2026-08-25 13:54 ` Alexandre Courbot
2026-08-25 14:02 ` Danilo Krummrich
2026-08-25 14:11 ` Gary Guo
2026-08-25 14:30 ` Alexandre Courbot
2026-08-25 12:04 ` Gary Guo
2026-08-25 2:44 ` [PATCH 2/2] gpu: nova-core: use kernel lossless integer conversion module Alexandre Courbot
2026-08-25 5:27 ` Eliot Courtney
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=DKYTZNAX6ON6.1K1372FFAQOF7@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=work@onurozkan.dev \
--cc=yury.norov@gmail.com \
--cc=zhiw@nvidia.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