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
