Re: [PATCH 0/7] Pre-requisite patches for mm and irq in nova-core

["Alexandre Courbot" <acourbot@nvidia.com>]

On Thu Oct 23, 2025 at 6:30 AM JST, Joel Fernandes wrote:
>> - The falcon interrupts patch does not seem to be used by the last two
>>   patches? I guess it belongs to the series that will add support for
>>   the interrupt controller.
> No, it is independent. Yes this leads up to the interrupt handing feature, but
> just to emphasize a bit, the motivation was to "get small patches" in so that we
> don't need to do obvious things later (example, the VFN interrupt module is much
> more complex than this GSP patch yet both are needed for interrupt handling, so
> the GSP patch is a good candidate IMO for upstreaming in the next merge window).
> Having small patches merged reduces future burden on both reviewers and the
> developers. This is also not something new, for instance we don't have any users
> of the PCI MSI IRQ allocation bindings in rust/, yet we merged those. I think
> that is reasonable. RFC should be used too when it makes sense, but I think we
> should also look into merging things in chunks to avoid future review/rebase
> burden. There isn't one rule that fits all is my point, right? I mean just look
> at the attempted bitfield move too, Nova is the only user yet we will move it
> out. But one may ask why move it out until there are other users? It has to be
> on a case-by-case basis..

We do have another user for bitfield/register and that's Tyr - the move
is to allow them to use these macros.

I am also more comfortable merging code when I understand how it is
called and used in practice. It doesn't necessarily need to be fully
complete, but something at least in RFC status demonstrating a real use
of the API helps.

Once a core patch in RFC status is reviewed and agreed on, it can be
added (with all the Reviewed-by tags) to the series containing its user
code, even if the user code comes later. It delays the merging of the
core code a bit, but since it has no user it would be dead merged code
anyway, and when you look at the whole picture it really comes down to
the same - there is no delay to when the machinery starts moving to
produce something useful.

Exceptions can be discussed if e.g. there is a big risk that a
refactoring will wreck everything, but this doesn't appear to be a
factor here.