Message-ID: <EF6C8A90-E911-4768-8B44-3750F29C9905@nvidia.com>
Date: Wed, 8 Oct 2025 19:56:20 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Yury Norov <yury.norov@...il.com>
CC: Daniel Almeida <daniel.almeida@...labora.com>, Alexandre Courbot
	<acourbot@...dia.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "dakr@...nel.org" <dakr@...nel.org>,
	Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>, Alex
 Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
	<gary@...yguo.net>, "bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, David
 Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
	<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, John Hubbard
	<jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	"joel@...lfernandes.org" <joel@...lfernandes.org>, Elle Rhumsaa
	<elle@...thered-steel.dev>, Andrea Righi <arighi@...dia.com>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to
 rust/kernel/




> On Oct 8, 2025, at 11:50 AM, Yury Norov <yury.norov@...il.com> wrote:
> On Tue, Oct 07, 2025 at 06:41:58PM -0300, Daniel Almeida wrote:
>> Hi,
>> 
>> First and foremost I’d like to say sorry for not having the bandwidth to
>> chime in here earlier. I’ve been pretty consumed by Tyr itself lately.
>> 
>>> On 7 Oct 2025, at 12:41, Yury Norov <yury.norov@...il.com> wrote:
>>> On Tue, Oct 07, 2025 at 07:36:21PM +0900, Alexandre Courbot wrote:
>>>> Hi Yuri,
>>>> On Tue Oct 7, 2025 at 7:29 AM JST, Yury Norov wrote:
>>>> <snip>
>>>>> Regardless, I don't think that this is the right path to move the
>>>>> bitfields into the core. The natural path for a feature that has
>>>>> been originally developed on driver side is to mature in there and
>>>>> get merged to core libraries after a while. Resctrl from Intel is one
>>>>> recent example.
>>>>> With that said, I'm OK if you move the bitfields as a whole, like you
>>>>> do in v5, and I'm also OK if you split out the part essential for nova
>>>>> and take it into the driver. In that case the bitfields will stay in
>>>>> drivers and you'll be able to focus on the features that _you_ need,
>>>>> not on generic considerations.
>>>>> I'm not OK to move bitfields in their current (v6) incomplete form in
>>>>> rust/kernel. We still have no solid understanding on the API and
>>>>> implementation that we've been all agreed on.
>>>> Initially the plan was indeed to give this code some more time to mature
>>>> in nova-core before moving it out.
>>>> The reason for the early move is that we have another driver (Tyr) who
>>>> wants to start using the register macro. Without it, they would be left
>>>> with the option of either reinventing the wheel, or poking at registers
>>>> the old-fashioned way, which I think we can agree is not going to be any
>>>> safer than the current macro. :)
>> 
>> Tyr could use both register!() and bitfield!() today FYI. If you move it out, I can
>> follow with an actual patch to do so.
> 
> Not sure I understand this. Does it mean that you have use cases
> for bitfields unrelated to I/O registers? Can you please share
> details on what you need and sketch some examples? Particularly,
> do you have arrays of bitfields in mind?
> 
> If my understanding is correct, then I think the strategy that
> meets your interests at best would be moving the registers out of
> Nova earlier. After that both Tyr and Nova people will get equally
> involved in bitfields (and possible BoundedInt) development.

Yes, but how would that help Nova? There does not seem to be much reason to not move it out together - did you see my email where I enlisted all the issues? Daniel was suggesting moving it out together, so he can use both, which afaics everyone here is agreeing on as well.

> 
> This is what Danilo proposed in the other email, and I agree that it's
> the most structured path.
> 
> Regarding timeline, I think 2-stage approach will eventually become
> faster.

Not really. Essentially that means duplicating the bitfield code both within nova and outside nova for no good reason. Nova needs bitfield and register both. Moving register out without bitfield means duplicating bitfield code within nova. We definitely do not want that. Also the work to move it out is already done.

I think I do not understand what are the technical reasons to hold it up any further? If you have a concern about being moved out together, please participate in the discussion where I sent a long email enlisting all the issues and we can discuss each issue there. We would want only technical reasons, not hypotheticals. As Alex said, there is a greater chance of badly written code if people reinvent these features themselves. Out of those issues in the long email, only the bounded integer is the open issue. But even that is not something that should be holding this up IMO since Alex already has RFC to fix it, and it does not really effect the API usage much. I think Alex had some very good reasons to move the code out as well and we can improve on the bounded integer issue further perhaps even before the next merge window.

Tyr will use both right away as Daniel mentioned, and I can say the same for Nova. So what is the problem?

No doubt there will be incremental improvements to both macros. They are in pretty good shape and there is no need to wait for them to be perfect. Let us not make perfection the enemy of progress :)

Thanks!

Joel


> 
> Thanks,
> Yury

Powered by blists - more mailing lists