Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool
John Hubbard <[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 | <[email protected]> |
On 8/13/26 2:44 PM, Yury Norov wrote: > On Thu, Aug 13, 2026 at 02:38:34PM -0700, John Hubbard wrote: >> On 8/13/26 1:58 PM, Gary Guo wrote: >>> On Thu Aug 13, 2026 at 9:48 PM BST, Danilo Krummrich wrote: >>>> On Thu Aug 13, 2026 at 8:32 PM CEST, Yury Norov wrote: >> ... >>>> The code from Eliot does actually already takes advantage of this. In >>>> >>>> pool.alloc_area(nz::<8>(), Alignment::new::<8>())?; >>> >>> I have to say this looks quite ugly, compared to just `.alloc_area(8, 8)`. In >>> this case I'd go with something aesthetically better... >> >> In addition to aesthetics, a practical concern is that there is a >> higher cognitive load to both reading and writing the longer form, >> above. Perhaps that is just the price one must pay. >> >> However, for primitive types, I am hearing (even from Miguel) that >> there might be a way to get the static checking *and* an easier >> interface. >> >> Here's hoping you all can find a way to do that. :) On second thought, we haven't talked about what the callers look like here, and .alloc_area(8, 8) could simply force the mess back into the call sites. > > There's a nice postfix macro proposal: > > computation().macro!().method().another_macro!() > > https://github.com/rust-lang/rfcs/pull/2442 > > That would solve the problem. But it doesn't move since 2024. I > recall it was mentioned in the bitfields discussion, but maybe > it's a false memory... thanks, -- John Hubbard