Re: [Qemu-devel] [libvirt] Changing qemu's -help output

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

On 07/25/2012 01:09 PM, Luiz Capitulino wrote:
> On Wed, 25 Jul 2012 20:02:53 +0100
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> On 25 July 2012 20:02, Luiz Capitulino <lcapitulino@redhat.com> wrote:
>>> On Wed, 25 Jul 2012 19:58:02 +0100
>>> Peter Maydell <peter.maydell@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@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]