NVIDIA GPU driver infrastructure
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
	"Alice Ryhl" <aliceryhl@google.com>
Cc: "Eliot Courtney" <ecourtney@nvidia.com>,
	"Burak Emir" <burak.emir@gmail.com>,
	"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>,
	"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>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"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, dri-devel@lists.freedesktop.org,
	dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v8 03/12] rust: num: add cv! macro to create values from constant expressions
Date: Thu, 27 Aug 2026 22:48:10 +0900	[thread overview]
Message-ID: <DKZRUNURZ645.1R1EVJ9ZEXFDE@nvidia.com> (raw)
In-Reply-To: <DKZOJLLRFT75.1967F9U9JUTVV@nvidia.com>

On Thu Aug 27, 2026 at 8:12 PM JST, Alexandre Courbot wrote:
> On Thu Aug 27, 2026 at 7:42 PM JST, Alexandre Courbot wrote:
>> On Thu Aug 27, 2026 at 6:32 PM JST, Alice Ryhl wrote:
>>> On Thu, Aug 27, 2026 at 04:28:31PM +0900, Eliot Courtney wrote:
>>>> Currently, using NonZero/Bounded constants is quite verbose. It's
>>>> unfortunate because it disincentivizes using it in interface boundaries.
>>>> Introduce a macro to make it nicer to use. The macro `cv!` (for constant
>>>> value) takes a const integer expression and widens it to i128 (at build
>>>> time only) before passing it as a const generic value to a new trait
>>>> function `FromConst::from_const`. The trait is implemented by NonZero,
>>>> Bounded, and Alignment and lets values of each be constructed from
>>>> constants without a verbose turbofish syntax. For example,
>>>> `const { NonZero::new(1).unwrap() }` can be written as `cv!(1)`.
>>>> 
>>>> Suggested-by: Gary Guo <gary@garyguo.net>
>>>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>>>
>>> This doesn't work in const context, so I don't think this is a great
>>> strategy.
>>>
>>> I would want to use it for cases like this:
>>>
>>> drivers/android/binder/netlink.rs
>>>         const BINDER_CMD_REPORT: u8 = kernel::uapi::BINDER_CMD_REPORT as u8;
>>>         const BINDER_A_REPORT_ERROR: c_int = kernel::uapi::BINDER_A_REPORT_ERROR as c_int;
>>>         const BINDER_A_REPORT_CONTEXT: c_int = kernel::uapi::BINDER_A_REPORT_CONTEXT as c_int;
>>>         const BINDER_A_REPORT_FROM_PID: c_int = kernel::uapi::BINDER_A_REPORT_FROM_PID as c_int;
>>>         const BINDER_A_REPORT_FROM_TID: c_int = kernel::uapi::BINDER_A_REPORT_FROM_TID as c_int;
>>>         const BINDER_A_REPORT_TO_PID: c_int = kernel::uapi::BINDER_A_REPORT_TO_PID as c_int;
>>>         const BINDER_A_REPORT_TO_TID: c_int = kernel::uapi::BINDER_A_REPORT_TO_TID as c_int;
>>>         const BINDER_A_REPORT_IS_REPLY: c_int = kernel::uapi::BINDER_A_REPORT_IS_REPLY as c_int;
>>>         const BINDER_A_REPORT_FLAGS: c_int = kernel::uapi::BINDER_A_REPORT_FLAGS as c_int;
>>>         const BINDER_A_REPORT_CODE: c_int = kernel::uapi::BINDER_A_REPORT_CODE as c_int;
>>>         const BINDER_A_REPORT_DATA_SIZE: c_int = kernel::uapi::BINDER_A_REPORT_DATA_SIZE as c_int;
>>
>> `const_as!` [1] should do the trick for this, provided you don't need to
>> create a const `NonZero`.
>>
>> [1] https://lore.kernel.org/all/20260825-const_as-v1-1-1ce712225fe2@nvidia.com/
>
> ... but I agree it would be nice to be able to use this in const
> context. And there is an overlap with `const_as!` that becomes more
> obvious the more I look at it.
>
> In for a penny, in for a pound of macro code as they say. Since we
> agreed on using macros, how about unifying both under the same `cv!`
> macro, with as many branches as we have types we want to initialize from
> a constant value? For instance:
>
>     // Does what `const_as!` currently does under the hood.
>     const BINDER_CMD_REPORT: u8 = cv!(u8::from(kernel::uapi::BINDER_CMD_REPORT));
>     // Calls `NonZero::new().unwrap()` under the hood.
>     const SOME_NONZERO: NonZero<u8> = cv!(NonZero::new(kernel::uapi::NONZERO_VALUE));
>     // Calls `Bounded::new::<{ ...}>()` under the hood.
>     const SOME_BOUNDED: Bounded<u32, 2> = cv!(Bounded::new(kernel::uapi::SMALL_VALUE));
>
> I.e. we would have one extra matching arm in `cv!` per type it handles
> instead of implementing a trait. The syntax of the macro would look more
> natural (bye bye `const_as`'s awkward `=>`), albeit it would have the
> limitations of such a semantic dispatch.
>
> Even the name `const_as!` wasn't really accurate to begin with: what it
> really emulates is a const `try_from`, and we even discussed
> implementing it in these terms in the future.
>
> I'm sure the idea needs more polishing but I think there's something to
> explore here.

Yeah I agree that const_as! is similar and if we had const traits we
could fully merge them and have it always work in a const context for
both duties (which are really a const tryfrom as you said).

I am not sure about the suggested syntax (e.g.
cv!(Bounded::new(kernel::uapi::SMALL_VALUE))), since it seems very
verbose.

Alternatively, what about just directly merging them so you use
cv!(5) (the non const context FromConst::from_const dispatcher in this
series) or cv!(value => u8) (exactly const_as!), with the =>
distinguishing between the two?

So this is what would work for Alice's example (const_as! but pushed
inside cv!):
```
const BINDER_CMD_REPORT: u8 = cv!(kernel::uapi::BINDER_CMD_REPORT => u8);
```

When we have const traits then we could remove the => syntax I think.

  reply	other threads:[~2026-08-27 13:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  7:28 [PATCH v8 00/12] rust: Add support for reserving of ranges of IDs Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 01/12] rust: bitmap: use function-level cfg on kunit test Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 02/12] rust: bitmap: restrict bitmap length to at most i32::MAX Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 03/12] rust: num: add cv! macro to create values from constant expressions Eliot Courtney
2026-08-27  9:32   ` Alice Ryhl
2026-08-27 10:42     ` Alexandre Courbot
2026-08-27 11:12       ` Alexandre Courbot
2026-08-27 13:48         ` Eliot Courtney [this message]
2026-08-27 13:59           ` Gary Guo
2026-08-27 14:29           ` Alexandre Courbot
2026-08-27 14:37             ` Gary Guo
2026-08-27 14:55               ` Alice Ryhl
2026-08-27  7:28 ` [PATCH v8 04/12] rust: prelude: add `num::cv` Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 05/12] rust: use cv! to build Bounded values from constants Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 06/12] rust: sizes: add sub-1K size constants Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 07/12] rust: sizes: implement SizeConstants for Alignment Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 08/12] rust: use Alignment size constants Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 09/12] rust: bitmap: add contiguous area operations Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 10/12] rust: id_pool: add contiguous ID reservation Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 11/12] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN Eliot Courtney
2026-08-27  7:28 ` [PATCH v8 12/12] gpu: nova-core: add ChannelIdPool 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=DKZRUNURZ645.1R1EVJ9ZEXFDE@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=burak.emir@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel-bounces@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --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=simona@ffwll.ch \
    --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