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

Burak Emir <[email protected]>
Newsgroups org.kernel.vger.rust-for-linux,dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel
Message-ID <CABwQupNA=NuctKz0FRaJsWowf+=24C_o7u8twFFeUZ+dq6u+Jw@mail.gmail.com>
On Mon, Aug 17, 2026 at 4:08 PM Danilo Krummrich <[email protected]> wrote:
>
> 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.
>

To add a minor point to this, if rustc could figure out that a
suitable non-zero number literal can be treated as NonZero<usize>,
we'd not need a macro and it would all be very ergonomic...

cheers,
- Burak
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.