From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
'@google.com, "Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Shashank Sharma" <shashanks@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"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>,
rust-for-linux@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] rust: sizes: add DeviceSize trait for device address space constants
Date: Fri, 03 Apr 2026 17:21:07 +0900 [thread overview]
Message-ID: <DHJDGQ1WAOP7.1BHAVWX0OSZXF@nvidia.com> (raw)
In-Reply-To: <f2ba20ab-7c56-4e57-ae71-06b35a696a44@nvidia.com>
On Fri Apr 3, 2026 at 10:36 AM JST, John Hubbard wrote:
> On 4/1/26 6:42 PM, Alexandre Courbot wrote:
>> On Thu Apr 2, 2026 at 6:20 AM JST, Danilo Krummrich wrote:
>>> On Wed Apr 1, 2026 at 10:22 PM CEST, John Hubbard wrote:
>>>> On 4/1/26 2:46 AM, Alice Ryhl wrote:
> ...
>>> The reason is that when I proposed this I was thinking of it as a marker trait
>>> for "complex" types around u32, u64, etc. that we can use in DRM APIs (or any
>>> other device centric API) though generics.
>>>
>>> For instance, instead of GpuVm<T>::vm_start() -> u64, it could be
>>> GpuVm<T, V: DeviceSize>::vm_start() -> V.
>>
>> With the proposed naming this becomes `GpuVm<T, V: SizeConstants>`. Why
>> not just name it `Size`? Sure it's a very common word, but we have the
>> module to scope the name properly.
>
> I was waiting to see if anyone else weighed in.
>
> SizeConstants accurately describes what this trait provides. Size is
> too general. Again, I think it's best to name things for what they
> are or what they provide. And then, if they look odd in some use case,
> that's a hint to consider if that use case is precisely the best way
> to compose what you want to do.
>
> Anyway, I'm pretty sold on SizeConstants, so I'm hoping to stay with
> that, are you OK with it?
Yes, as mentioned on my v4 review. I agree `SizeConstants` describes
what this trait provides currently - but was also thinking that this
trait might grow into depending on some arithmetic operations to allow
generic code to be written for anything that is a size in the general
sense.
That being said, we can also write said generic code by depending on the
required ops explicitly, so limiting the trait to providing constants
doesn't really limit us.
next prev parent reply other threads:[~2026-04-03 8:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 22:43 [PATCH v3 0/2] rust, nova-core: add DeviceSize trait for SZ_* constants John Hubbard
2026-03-31 22:43 ` [PATCH v3 1/2] rust: sizes: add DeviceSize trait for device address space constants John Hubbard
2026-04-01 9:46 ` Alice Ryhl
2026-04-01 20:22 ` John Hubbard
2026-04-01 21:20 ` Danilo Krummrich
2026-04-01 21:29 ` John Hubbard
2026-04-02 1:42 ` Alexandre Courbot
2026-04-03 1:36 ` John Hubbard
2026-04-03 8:21 ` Alexandre Courbot [this message]
2026-04-03 12:56 ` Gary Guo
2026-04-03 13:07 ` Danilo Krummrich
2026-04-04 1:46 ` John Hubbard
2026-04-01 10:16 ` Miguel Ojeda
2026-04-01 20:33 ` John Hubbard
2026-03-31 22:43 ` [PATCH v3 2/2] gpu: nova-core: use DeviceSize trait for u64 size constants John Hubbard
2026-04-01 7:01 ` [PATCH v3 0/2] rust, nova-core: add DeviceSize trait for SZ_* constants Eliot Courtney
2026-04-01 20:46 ` John Hubbard
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=DHJDGQ1WAOP7.1BHAVWX0OSZXF@nvidia.com \
--to=acourbot@nvidia.com \
--cc='@google.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shashanks@nvidia.com \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.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