Re: [PATCH v3 1/2] rust: sizes: add DeviceSize trait for device address space constants

[John Hubbard <jhubbard@nvidia.com>]

On 4/1/26 2:20 PM, 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:
>>> On Tue, Mar 31, 2026 at 03:43:18PM -0700, John Hubbard wrote:
...
>>> The name `DeviceSize` seems overly specific to the use-case you had. It
>>
>> Yes, actually this name has been worrying me from the start. Because
>> it is not necessary to tie it, conceptually, to devices at all.
>>
>>> also makes it sound like something you would implement *for* the device
>>> type rather than for the integer type. Why not name it something more
>>> generic such as SizeConstants?
>>
>> Yes, thanks, I do think SizeConstants is more accurate.
>>
>> I'm inclined to make that change, unless someone else tells me not
>> to...let's see.
> 
> I think I brought up the name DeviceSize when I proposed this.

I let this patchset linger so long in my backlog that I forgot the
trait's naming provenance. :)

> 
> 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.
> 
> Another example would be buddy::Block<V: DeviceSize>::offset() -> V instead of
> buddy::Block::offset() -> u64.
> 
> This way you can interact with the API with the actual device native size.

Yes. But it's an uneasy fit, somehow. I can (again) see the idea, but
it's also true that SizeConstants is something that is generally
desirable elsewhere, too.

> 
> That said, I'm perfectly fine renaming this to something else; the "device

Excellent!

> semantics" comes from the API using the type, not the type itself.

That's exactly where I landed, too. And of course, when naming APIs,
it's best to pick names that describe what the API provides, rather
than to (often imperfectly) predict what current and future callers
may do. 


thanks,
-- 
John Hubbard