[libvirt] Changing qemu's -help output

Eric Blake eblake at redhat.com
Wed Jul 25 21:21:01 UTC 2012


On 07/25/2012 01:09 PM, Luiz Capitulino wrote:
> On Wed, 25 Jul 2012 20:02:53 +0100
> Peter Maydell <peter.maydell at linaro.org> wrote:
> 
>> On 25 July 2012 20:02, Luiz Capitulino <lcapitulino at redhat.com> wrote:
>>> On Wed, 25 Jul 2012 19:58:02 +0100
>>> Peter Maydell <peter.maydell at linaro.org> wrote:
>>>> I think we should simply say "no, parsing -help is broken and wrong and it
>>>> was obviously broken and wrong and we are in fact going to change the
>>>> help output for QEMU 1.2, and you will need a new libvirt that can
>>>> cope with that". We can't be held hostage forever to really bad decisions
>>>> like that.
>>>
>>> We have to provide an alternative before doing that.
>>
>> Try whatever it is you wanted to try, see if it barfs. Or don't use it.
> 
> Libvirt folks can answer if this is feasible (CC'ing them), I'd guess it's not.

I'm all for breaking -help output, provided we have something more
reliable to use in its place.  The way I see it, we have these scenarios
to think about:

old libvirt, old qemu => works
new libvirt, new qemu => works
new libvirt, old qemu => works (and if it doesn't, it's libvirt's fault,
so this is irrelevant to qemu)
old libvirt, new qemu => this is what _might_ break if -help output
changes; but if you can afford to upgrade qemu, you should also be able
to upgrade your libvirt.  A historical example of this was when qemu
upgraded to 1.0, but older libvirt was still expecting to parse a x.y.z
version string, so the reality was that no one upgraded to qemu 1.0
unless they also upgraded libvirt.

We've already known for some time that parsing -help output is fragile;
the best we can do is make sure that new libvirt can handle all
historical forms of output, but I think it is reasonable to tell users
that as soon as a new form of output is added to the mix (because qemu
was upgraded), then you also have to upgrade libvirt to handle that new
format.  Older libvirt's inability to predict the future of what newer
qemu output will be should not penalize innovation in newer qemu.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120725/d2f018a6/attachment-0001.sig>


More information about the libvir-list mailing list