Re: [Qemu-devel] [Spice-devel] [PATCH] [RFC] LZ4 compression option for SPICE

[Javier Celaya <javier.celaya@flexvm.es>]

>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.

El Martes, 27 de enero de 2015 09:26:11 Markus Armbruster escribió:
> Eric Blake <eblake@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.