On 07/25/2012 01:09 PM, Luiz Capitulino wrote: > On Wed, 25 Jul 2012 20:02:53 +0100 > Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > >> On 25 July 2012 20:02, Luiz Capitulino <lcapitulino@xxxxxxxxxx> wrote: >>> On Wed, 25 Jul 2012 19:58:02 +0100 >>> Peter Maydell <peter.maydell@xxxxxxxxxx> 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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list