Re: [Qemu-devel] [PATCH 0/7] qapi: add commands to remove the need to parse -help output

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 27 Jul 2012 08:37:12 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> This series implements the necessary commands to implements danpb's idea to
> remove -help parsing in libvirt.  We would introduce all of these commands in
> 1.2 and then change the -help output starting in 1.3.

I've reviewed this and apart from small details, it looks good to me.

Would be nice to get an ack from libvirt folks before applying.

> 
> Here is Dan's plan from a previous thread:
> 
> <danpb>
> 
>  Basically I'd sum up my new idea as "just use QMP".
> 
>   * No new command line arguments like -capabilities
> 
>   * libvirt invokes something like
> 
>       $QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
> 
>   * libvirt then runs a number of  QMP commands to find out
>     what it needs to know. I'd expect the following existing
>     commands would be used
> 
>       - query-version             - already supported
>       - query-commands            - already supported
>       - query-events              - already supported
>       - query-kvm                 - already supported
>       - qom-{list,list-types,get} - already supported
>       - query-spice/vnc           - already supported
> 
>  And add the following new commands
> 
>       - query-devices             - new, -device ?, and/or -device NAME,? data
>  in QMP
>       - query-machines            - new, -M ? in QMP
>       - query-cpu-types           - new, -cpu ? in QMP
> 
>  The above would take care of probably 50% of the current libvirt
>  capabilities probing, including a portion of the -help stuff. Then
>  there is all the rest of the crap we detect from the -help. We could
>  just take the view, that "as of 1.2", we assume everything we previously
>  detected is just available by default, and thus don't need to probe
>  it.  For stuff that is QOM based, I expect we'll be able to detect new
>  features in the future using the qom-XXX monitor commands. For stuff
>  that is non-qdev, and non-qom, libvirt can just do a plain version
>  number check, unless we decide there is specific info worth exposing
>  via other new 'query-XXX' monitor commands.
>  Basically I'd sum up my new idea as "just use QMP".
> 
>   * No new command line arguments like -capabilities
> 
>   * libvirt invokes something like
> 
>       $QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
> 
>   * libvirt then runs a number of  QMP commands to find out
>     what it needs to know. I'd expect the following existing
>     commands would be used
> 
>       - query-version             - already supported
>       - query-commands            - already supported
>       - query-events              - already supported
>       - query-kvm                 - already supported
>       - qom-{list,list-types,get} - already supported
>       - query-spice/vnc           - already supported
> 
>     And add the following new commands
> 
>       - query-devices             - new, -device ?, and/or -device NAME,? data
>  in QMP
>       - query-machines            - new, -M ? in QMP
>       - query-cpu-types           - new, -cpu ? in QMP
> 
>  The above would take care of probably 50% of the current libvirt
>  capabilities probing, including a portion of the -help stuff. Then
>  there is all the rest of the crap we detect from the -help. We could
>  just take the view, that "as of 1.2", we assume everything we previously
>  detected is just available by default, and thus don't need to probe
>  it.  For stuff that is QOM based, I expect we'll be able to detect new
>  features in the future using the qom-XXX monitor commands. For stuff
>  that is non-qdev, and non-qom, libvirt can just do a plain version
>  number check, unless we decide there is specific info worth exposing
>  via other new 'query-XXX' monitor commands.
> 
> </danpb>
> 
> The one thing to note is that I didn't add a query-devices command because you
> can already do:
> 
> qmp query-devices --implements=device --abstract=False
> 
> To get the equivalent output of -device ?.  Instead, I added a command to list
> specific properties of a device which is the equivalent of -device FOO,?
> 
>