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

John Hubbard <[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 <[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
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.