Re: [PATCH 0/6] rust: add `bitfield!` and `register!` macros

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Jan 20, 2026 at 4:48 PM CET, Miguel Ojeda wrote:
> On Tue, Jan 20, 2026 at 4:27 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> I think it's just about pasting the current bitfield work into register.rs, such
>> that it can only be used from there. In a follow up we can work out how it
>> should turn out finally and have to patches: 1. introduce bitfield.rs and 2.
>> move register!() to use the code from bitfield.rs.
>
> Hmm... I am generally not a fan of putting local code. I know you did
> it for the DRM `register!` itself, which is fine given the constraints
> you have, but here perhaps we could put it in the right file but as
> private/hidden as possible just to be used by the other file?
>
> i.e. that way we can debate improvements on top of what we have,
> rather than having a move or new code and a drop of the old one?

I'm fine either way; the reason I proposed it the way I did was that I think it
sets the least precedence for how bitfields should turn out eventually.

> I mention this since you say "pasting", i.e. I guess it is still
> smaller, but it sounds like you would essentially use it more or less
> as-is?

I left this to Alex, he knows best what makes sense.

>> The register!() macro code is worked on by Alex for about 10 month in nova-core,
>> the first RFC for general I/O infrastructure is from March 2025 and the current
>> series has been discussed on the list for about two cycles.
>
> I meant the `bitfield!` one, i.e. landing the patches as they are here
> if we get very fast agreement etc. etc. I can see that possibility,
> especially if private/hidden.

I think it's rather unlikely to land bitfields this cycle. I think Yury
explicitly requested more discussion on bitfields and also encouraged the "two
stage" approach [1] moving register!() first and then extract bitfields
subsequently.

[1] https://lore.kernel.org/lkml/aOaIIV8KDA0GjF6E@yury/