On Fri, 27 Jul 2012 08:37:12 -0500
Anthony Liguori <aliguori@xxxxxxxxxx> 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,?
>
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list