On Fri, Jun 18, 2021 at 07:52:47AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > > > On Thu, Jun 17, 2021 at 05:53:11PM +0200, Claudio Fontana wrote: > >> On 6/17/21 5:39 PM, Valeriy Vdovin wrote: > >> > On Thu, Jun 17, 2021 at 04:14:17PM +0200, Markus Armbruster wrote: > >> >> Claudio Fontana <cfontana@xxxxxxx> writes: > >> >> > >> >>> On 6/17/21 1:09 PM, Markus Armbruster wrote: > > [...] > > >> >>>> If it just isn't implemented for anything but KVM, then putting "kvm" > >> >>>> into the command name is a bad idea. Also, the commit message should > >> >>>> briefly note the restriction to KVM. > >> >> > >> >> Perhaps this one is closer to reality. > >> >> > >> > I agree. > >> > What command name do you suggest? > >> > >> query-exposed-cpuid? > > > > Pasting the reply I sent at [1]: > > > > I don't really mind how the command is called, but I would prefer > > to add a more complex abstraction only if maintainers of other > > accelerators are interested and volunteer to provide similar > > functionality. I don't want to introduce complexity for use > > cases that may not even exist. > > > > I'm expecting this to be just a debugging mechanism, not a stable > > API to be maintained and supported for decades. (Maybe a "x-" > > prefix should be added to indicate that?) > > > > [1] https://lore.kernel.org/qemu-devel/20210602204604.crsxvqixkkll4ef4@xxxxxxxxxxx > > x-query-x86_64-cpuid? > Unless somebody wants to spend time designing a generic abstraction around this (and justify the extra complexity), this is a KVM-specific command. Is there a reason to avoid "kvm" in the command name? -- Eduardo
