Re: [Qemu-devel] [PATCH 00/19] RFC: Reporting QEMU binary capabilities

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> writes:

[...]
> The main problem encountered with this patch series is the
> split between argv and config parameters. The qemu-config.c
> file provides the information is a good data format, allowing
> programatic access to the list of parameters for each config
> option (eg, the 'cache', 'file', 'aio', etc bits for -drive).
> There are some issues with it though
>
>  - It lacks a huge amount of coverage wrt to the full argv
>    available, even simple things like the '-m' argument
>    don't exist.
>
>  - It is inconsistent in handling parameters. eg it  hands
>    off validation of netdev backends to other code, to allow
>    for handling of different parameters for tap vs user vs
>    socket backends.  For chardev backends though, it directly
>    includes a union of all possible parameters.

The problem behind this "inconsistency" (first order approximation):
there are fixed options, and several sets of variable options.  One of
the fixed options is the discriminator, and its value determines which
set of variable options applies.

You can ignore this and put all variable options right into the
QemuOptsList.desc[].  qemu-option still catches "alway-invalid" options,
but application code needs to check again.  If the variable sets
conflict, we're reduced to QEMU_OPT_STRING type, and have to leave
type-checking to application code.

We can also have an empty desc[], and simply leave all of the validation
job to application code.  Typical way to do it: get discriminator value,
look up its desc[], pass it to qemu_opts_validate().  This is how
-netdev works.  Drawbacks: duplicates fixed options in every desc[],
even fixed options are hidden fairly deep in application code.

It's easy to do better for fixed options: put them in
QemuOptsList.desc[], use qemu_opts_validate() only for the variable
options.  I hope to post a patch for that soon.

Pulling the variable options out of application code is a bit harder.
More so for -device than for -netdev.

[...]