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

[Danilo Krummrich]

On Mon Aug 17, 2026 at 3:02 PM CEST, Gary Guo wrote:
> Now, with `NonZero` or `Bounded`, we are doing none of that. The only thing here
> is that there is a range restriction. Other than the value restriction
> themselves, they carry no other semantic meanings. How you interpret these types
> still fully depend on the API that accepts them. Therefore, it is very common
> that you'd be using these with literals, and it becomes an ergnomic pain.

I agree that NonZero and Bounded are on the weaker end of the argument. But
there's still the flexibility argument.

The API itself, i.e. alloc_area(), does not need to bother with how the value is
checked. I.e. is it a runtime check, compile or build time check, or is it even
unchecked (or panicking) because we can derive the invariant from another type.

> Personally I value ergnomics higher than possibility of misuse if latter can
> be easily mitigated otherwise (in this case, by WARN_ON or just support
> zero-sized alloc).

Both is not a mitigation IMO.

WARN_ON() is does not prevent misuse of the API in the first place and in case
the value comes from userspace even introduces a vulnerability.

Making zero a valid argument simply ignores the problem or just moves it
elsewhere, e.g. where the caller has to validate the returned type instead, i.e.
the ChannelIdArea. IOW, we'd remove the invariant ChannelIdArea carries.