Re: [PATCH v2 8/9] gpu: nova-core: gsp: move the RPC commands into a sub-module

[Alexandre Courbot]

On Tue Sep 29, 2026 at 12:11 AM JST, Zhi Wang wrote:
> On Mon, 28 Sep 2026 20:40:08 +0900
> "Alexandre Courbot" <acourbot@xxxxxxxxxx> wrote:
>
>> On Mon Sep 28, 2026 at 6:20 PM JST, Zhi Wang wrote:
>> > On Sun, 27 Sep 2026 22:46:25 +0900
>> > Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
>> >  
>> >> Move the types and code related to RPC commands into the
>> >> `rpc` sub-module, and update their users to reference them from
>> >> their new location.
>> >> 
>> >> This is a pure move commit, with no functional change intended.
>> >>   
>> >
>> > Hi Alex:
>> >
>> > What would be the plan for commands.rs in the future after the
>> > movement? I was adopting the similar code structures
>> > (fw.rs/command.rs) for vGPU manager's RPCs and GSP plugin RPCs,
>> > e.g. having RPC typed code and function handler(wrapper)s, it would
>> > be nice that I can align with the idea accordingly.  
>> 
>> Can you point me to the the structure you have if it is posted?
>> (sorry, too many series in-flight and I cannot find where it is ^_^;)
>> 
>
> No worry.
>
> I am trying to maintain vGPU-related RPCs and GSP plugin RPCs in below
> two files. Basically the maintaining schema is similar to current
> nova-core fw.rs and commands.rs. 
>
> IMO, nova-core and vGPU managers bindings should stay together, but
> there can be quite many vGPU RPCs. Would it be a good idea to maintain
> them together with nova-core's fw.rs and commands.rs?

Unless there is a good reason not to do so, I'd put all vGPU commands
into their own submodule. This makes it easier to e.g. create a version
of the driver without vGPU support, which I feel like we may end up
putting behind a Kconfig option since it won't be relevant to
consumer-grade GPUs.

Bindings are a different story, they are generated in one go and unused
ones are just optimized away, so having them all in the same file is fine.