On Mon, Oct 03, 2016 at 16:04:42 -0300, Eduardo Habkost wrote:
> Hi,
>
> When adding new QMP commands that are implemented by
> arch-specific code, we have been adding stubs that report
> QERR_UNSUPPORTED (see stubs/arch-query-cpu-model-expansion.c for
> an example).
>
> But we are using GenericError for that, and this prevents clients
> from reliably checking if the command is really implemented by
> the QEMU binary.
>
> What should be the right solution for this? Some of the options I
> have considered are:
>
> 1) Using CommandNotFound as the error class in the stubs. This
> sounds wrong because the command exists (it is present in
> query-commands and in the QAPI schema).
> 2) Creating a CommandNotImplemented error class. Simple to do,
> but it would require clients to make two separate checks,
> before concluding that the command is available (checking
> query-commands or query-qmp-schema, and then checking for
> CommandNotImplemented errors).
Both options require an extra step to check whether a particular command
is implemented or not. It would be highly appreciated if we didn't have
to go this way since it would seriously complicate the probing process.
We'd need to run each command with some artificial, but sane enough
arguments to bypass arguments checking code:
(QEMU) query-cpu-model-expansion type=full
{"error": {"class": "GenericError", "desc": "Invalid parameter type for
'model', expected: QDict"}}
(QEMU) query-cpu-model-expansion type=full model={'name':'host'}
{"error": {"class": "GenericError", "desc": "this feature or command is
not currently supported"}}
(QEMU) query-cpu-model-expansion type=full model={'name':'Penryn'}
{"error": {"class": "GenericError", "desc": "this feature or command is
not currently supported"}}
> 3.1) Removing the command from query-commands and from the QAPI
> schema on binaries that don't implement the command.
> Needlessly complex?
> 3.2) Removing the unimplemented command from query-commands only
> (by calling qmp_disable_command()), but keeping it on the QAPI
> schema. I am not sure it's OK to do that. If it is, this
> sounds like the simplest solution.
These options are both acceptable to libvirt. So it really depends what
is acceptable to QEMU...
>From my POV (which is quite ignorant to QEMU internals in this area),
there are a few other options:
- implementing a new QMP command to list unsupported commands
(e.g., query-unsupported-commands)
- adding a flag to qmp-schema which would indicate whether a command is
supported or not
- even a new stupid command that would take another command as an
argument and return whether it's supported or not would be better than
having to run each command individually with special arguments
I'm not saying these options are clean or doable, I'm just brainstorming
here.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list