On Tue Sep 29, 2026 at 12:11 AM JST, Zhi Wang wrote: > On Mon, 28 Sep 2026 20:40:08 +0900 > "Alexandre Courbot" <[email protected]> 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 <[email protected]> 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.
