Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool
Miguel Ojeda <[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 | <CANiq72nFwdXcN+C8nJhd5Yq-cdUp1CDw_2u-D+zkgvW1-a5dLQ@mail.gmail.com> |
On Tue, Aug 18, 2026 at 12:40 AM Yury Norov <[email protected]> wrote: > > Again, any kernel API trusts it's caller. It holds for assembler, > for C, and I don't see any reason why it shouldn't hold for Rust. Because the more you trust callers, the more complexity you are adding to keep everything dancing in sync, and thus the more perfect you have to be on every subsequent patch that modifies any code. So this is all about not having to trust callers as much as possible -- the point of using Rust in the kernel is to prevent mistakes using the stronger type system. And preventing mistakes is not just about memory safety. That is, even if `f(0)` is not UB, we still want to consider whether it is worth using the type system to prevent such an input. In other words, yes, restricting inputs to functions as much as possible allows us to convert certain functions from unsafe to safe ones, but it doesn't mean we have to stop there: we use the type system to prevent other mistakes too. We can even have types that do not restrict in any way the inputs value-wise, i.e. they may be pure wrappers of a primitive integer, to prevent mishandling such as passing the wrong kind of unit or mixing up two parameters. Now, particular cases may or may not be worth it, but the general principle stands. Cheers, Miguel