Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/

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

On Tue Oct 7, 2025 at 11:08 PM CEST, Joel Fernandes wrote:
> Danilo, Yuri, Miguel, John, all,
>
> On 10/7/2025 9:16 AM, Danilo Krummrich wrote:
>> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
>>> Because letting it fully mature within nova-core also has the drawback
>>> that we might miss the perspective of other potential users, which may
>>> make us draw ourselves into a corner that will make the macro less
>>> useful generally speaking. We are at a stage where we can still make
>>> design changes if needed, but we need to hear from other users, and
>>> these won't come as long as the macro is in nova-core.
>> 
>> There are two different things here that are getting mixed up a bit.
>> 
>>   (1) Moving the register!() code out of nova-core to make it accessible for
>>       other drivers.
>> 
>>   (2) Generalize the bitfield implementation that so far is baked into the
>>       register!() code.
>> 
>> Both of those make sense, but they don't have to happen at the same time
>> necessarily.
>> 
>> Now, I'm not saying that we necessarily have to change the approach here. The
>> current merge window isn't even closed, so we have plently of time left, i.e.
>> there's no rush with with patch series.
>> 
>> However, if it helps, I'm perfectly fine to take the register!() implementation
>> into the I/O entry in a first step and in a second step generalize the bitfield
>> implementation and move it out of the register!() code.
>> 
>> Again, there's no rush as far as I'm concerned, yet the latter approach might
>> add a bit more structure and hence run a bit smoother.
>
> In my view it is better to move both bitfield and register macros together
> because if we only moved register, it means we would have no bitfield support
> for the page table / mm use case I just posted a patch for (which is why I
> started looking into Bitfield support initially) unless we create a copy of just
> the bitfield code within nova which we definitely shouldn't I think. So I think
> it is best to move both.

Again, fine for me either way, but I wanted to open the possibility.

Typically, things run more smoothly when focusing on one thing at a time.
Especially when one thing is done to unblock something else, while the other
things needs some more discussion and might require a more slow-paced approach.)

(Slightly off-topic: Regarding the bitfields for page table management: Are we
sure that we can use raw bitfields for this? I.e. will we always be able to
configure the GPU to match CPU endianness?)

> For the IO (register macro) change, I can add add an entry to the existing IO
> record.

I don't think any changes are needed, it should be covered by just moving it to
rust/kernel/io/register.rs.

Thanks,
Danilo