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

Miguel Ojeda <[email protected]>
Newsgroups org.freedesktop.lists.dri-devel,dev.linux.lists.nova-gpu,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux
Message-ID <CANiq72mDrC+43kbj-X0dpSKP6zFM61R3QFPa+2_xKEP-RHUppw@mail.gmail.com>
On Thu, Aug 13, 2026 at 8:32 PM Yury Norov <[email protected]> wrote:
>
> Not OK is complicating interfaces and life of your users.

No, we don't want to introduce interfaces with unconstrained integers,
especially so when we have already types that express what we want.

In other words, we don't want to introduce impossible states and error
paths that aren't needed -- we want to rule them out statically. That
is the point of all of what we are doing with Rust.

The unconstrained interface you are proposing is actually the
complicated one, because it means now you have to provide more
documentation about both the allowed input values and the new error
cases. Not only that, you have to provide more tests for all that. And
you have to duplicate information that types like `Alignment` already
explain if you click on them.

And on the callee side, similarly, if someone already has e.g. an
`Alignment`, then we don't want users to be forced to convert back to
an unconstrained integer just to call the function that requires an
alignment to begin with.

Now, if a function is truly something that we want to call with e.g.
integer literals all the time, then maybe it is worth a workaround --
but those cases are rare, and even then it is likely to just be a
wrapper to the normal interface.

Cheers,
Miguel
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.