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

[Zhi Wang]

On Tue, 29 Sep 2026 23:40:22 +0900
"Alexandre Courbot" <acourbot@xxxxxxxxxx> wrote:

> 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.
> 

I see. Thanks for the clarification. This is the exact direction in my
current code. We can plan more on the detailed parts when you are
reviewing my patches. :)