The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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.

  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