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

[Eliot Courtney]

On Mon Aug 17, 2026 at 9:16 PM JST, Danilo Krummrich wrote:
> On Mon Aug 17, 2026 at 1:49 PM CEST, Eliot Courtney wrote:
>> On Mon Aug 17, 2026 at 8:18 PM JST, Danilo Krummrich wrote:
>>> On Mon Aug 17, 2026 at 12:54 PM CEST, Gary Guo wrote:
>>>> IMO we can just support zero-sized allocation by always succeeding, similar to
>>>> how ZST allocation is handled in memory allocation.
>>>
>>> Probably, but in contrast to ZST allocations it wouldn't be very useful, so we'd
>>> silently succeed on something that never was a reasonable argument in the first
>>> palce.
>>
>> Yeah I agree that supporting a generalised zero sized alloc is in some
>> ways conceptually nicer, but I also can't see any good reason why you
>> would want to do it, it sounds like a bug. That's also why in the latest
>> version I made IdPool also not allow a zero capacity [1] (incidentally
>> required to not have to change the grow code to avoid trying to double a
>> zero capacity thing every time).
>
> (I assume this is more a reply to Gary?)

Yes, and so was the below too kinda. Sorry for the confusion.

>
>> Tbh, I feel that NonZero (and Alignment) is hard to use currently
>> because of these ergonomics issues. But I reckon they're useful, so I
>> like the idea of trying to making them easier to use. Maybe you can make
>> an argument to not use NonZero here, but what about all the other times
>> we will want to use it?
>
> Personally, I don't see the argument for not using NonZero (or Alignment); the
> invariants required by the API are expressed very well by those types.
>
> I also don't see a reason to step back from using those types for this API. If
> we'd do so it would question all the other new types we have over primitives
> carrying certain invariants to a certain extend as well.
>
> I understand the ergonomics concern, and I also see that for compile time
> evaluation turbofish syntax is not that popular, but this can be improved.
>
> The fundamental value remains that it nicely separates the invariants callers
> need to uphold about certain arguments from the API itself. It makes the code
> more maintainable (e.g. we don't need 10 different variants of a function
> depending on whether the value is a compile time, build time or run time value)
> and it makes the code more readable and robust (e.g. the semantic meaning of
> arguments is very obvious and confusing arguments becomes almost impossible).