Please don't top-quote.

Javier Celaya <javier.cel...@flexvm.es> writes:

> El Martes, 27 de enero de 2015 09:26:11 Markus Armbruster escribió:
>> Eric Blake <ebl...@redhat.com> writes:
>> > On 01/26/2015 01:48 AM, Javier Celaya wrote:
>> >> Sorry, I forgot to patch the command-line help. Hope it helps.
>> >> 
>> >>>> Recently, SPICE included the lz4 compression algorithm. This patch adds
>> >>>> a command line option to select it.
>> >>> 
>> >>> How is libvirt going to introspect whether the command line supports
>> >>> this option?  Is there some QMP command that lists the set of valid
>> >>> compression formats understood by a given qemu binary?
>> > 
>> > No, patching the command line --help does NOT help libvirt.  It needs to
>> > be discoverable via QMP to be introspectible, as scraping --help output
>> > is not machine-friendly.  (That said, you DO want to expose it in --help
>> > output; I'm just complaining that --help output alone is not enough).
>> 
>> We should really, really, really provide access to (the relevant subset
>> of) the QAPI schema over QMP!  Until we get that, useful progress is
>> delayed by problems like this one, and we keep growing special-purpose
>> solutions to problems like this one.
>
>>From what I've seen in QEMU and libvirt's code, I would say that discovering 
> whether the spice server supports LZ4 is not a matter of adding a new QMP 
> command. That would not scale very well with new command line options. I 
> would 
> suggest something more general. For instance, having the command query-
> command-line-options return also the allowed values for string parameters. 
> That would output "lz4" for parameter "image-compression" in option "spice", 
> among the other compression methods. Another possibility would be a new QMP 
> command that returns the capabilities of the spice server, as defined in the 
> spice protocol. They include the SPICE_DISPLAY_CAP_LZ4_COMPRESSION 
> capability, 
> if the spice server supports LZ4. In any case, I think it is out of the scope 
> of this patch.

We already have a language to describe interfaces: QAPI schema.  It
already covers QMP.  I propose to reuse it for QMP introspection instead
of inventing yet another language.

Unfortunately, it doesn't cover the command line.  Recasting the command
line in QAPI sounds sensible to me, but it's non-trivial, and so far
nobody has volunteered to try.  So we'll likely need a stop-gap, like
extending query-command-line-options.  I don't like growing more
external interface languages, but I don't have better ideas.

Reply via email to