Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool

On Mon Aug 17, 2026 at 8:03 AM BST, Eliot Courtney wrote:
> On Fri Aug 14, 2026 at 11:53 PM JST, Yury Norov wrote:
>> On Fri, Aug 14, 2026 at 05:08:43AM -0400, Yury Norov wrote:
>>> On Fri, Aug 14, 2026 at 01:54:24PM +0900, Eliot Courtney wrote:
>>> > > 1. Provide a nz! macro to create constant non-zero things. Provide some
>>> > >    constants for common alignments
>>> > >
>>> > > Potentially, we could use build_assert! for cases it is provably
>>> > > non-zero but not a literal (although tbh not sure this is a good idea -
>>> > > at least not do this initially). 
>>> > >
>>> > > So either: nz!: const { NonZero::new(value).unwrap() }, or, nz!: some
>>> > > build assert gated construction of NonZero. A general nz! macro could
>>> > > also help ergonomics for other use cases too.
>>> > >
>>> > > That looks like this:
>>> > >
>>> > > pool.alloc_area(nz!(8), Alignment::AL_8)?;
>>> > 
>>> > Actually found that if we implement SizeConstants for Alignment then we
>>> > can get Alignment::SZ_4K etc almost for free.
>>> 
>>> Then maybe pass SZ_4K directly, and allow the alloc_area() to
>>> calculate the alignment:
>>> 
>>>         pool.alloc_area(nz!(8), SZ_4K)?;
>>
>> Even worse, you can advertise the function like: allocate a contiguous
>> set of channel IDs enough to represent XXX bytes of memory with YYY
>> alignment. And that way, you'll be able to do:
>>
>>           pool.alloc_area(SZ_8K, SZ_4K)?;
>>
>> If my understanding of the function is right, it would be a clear
>> improvement, because the user now doesn't think about ID channels pool
>> as a set of bits, but an abstraction over the memory access technique,
>> which it really is.
>
> If we pass SZ_4K directly, we are back to using plain integers, which is
> not what we should be doing for rust interfaces according to Miguel. Let
> me send a new version of this with my Alignment constants + nz! macro
> idea, IMO it helps with the verbosity.

I'm still not convinced with the `nz!` idea. Having to have a macro invocation
for each call is excessive.

IMO we can just support zero-sized allocation by always succeeding, similar to
how ZST allocation is handled in memory allocation.

Best,
Gary