qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'
Date: Fri, 14 May 2010 14:25:39 +0100
User-agent: Mutt/1.4.1i

On Fri, May 14, 2010 at 08:17:50AM -0500, Anthony Liguori wrote:
> On 05/12/2010 03:48 PM, Cole Robinson wrote:
> >On 05/12/2010 04:38 PM, Jes Sorensen wrote:
> >   
> >>On 05/12/10 22:29, Cole Robinson wrote:
> >>     
> >>>Commit f75ca1ae205f24dae296c82d534c37746f87232f changed the version
> >>>string from:
> >>>
> >>>QEMU PC Emulator version x.yy.z
> >>>
> >>>to
> >>>
> >>>QEMU Emulator version x.yy.z
> >>>
> >>>libvirt is overly sensitive to the format of this string, and barfs when
> >>>trying to parse qemu -help output. While libvirt should certainly be more
> >>>robust here, changing the output format of -version for cosmetic reasons
> >>>doesn't seem like the best idea, so let's revert the change and add a
> >>>comment explaining the issue.
> >>>       
> >>Rather than this, I would prefer a -version argument that just returns
> >>the current QEMU version string.
> >>
> >>IMHO it's not a good approach to do static string matching.
> >>
> >>     
> >I agree libvirt's method is a crappy approach. Adding a proper -version
> >argument is certainly the way forward, but doesn't help users with
> >existing libvirt installations that want to use latest qemu. This is the
> >type of issue that libvirt devs will be fielding for months. Ideally i'd
> >like the order to be:
> >
> >1) Apply this patch
> >2) Add a proper -version argument, maybe named -version_num
> >3) libvirt patched to use new version argument (and robustify legacy
> >version parsing)
> >4) Some reasonable amount of time from now (6 months, a year?), edit the
> >current -version string at will
> >
> >I'd be willing to do 2 and 3 if people agree.
> >   
> 
> I'd like to see exactly what information libvirt needs so that we can 
> agree on the proper interface to obtain it.  My concern is that we'd 
> have the same problem with the version string.
> 
> This topic has come up many times in the past.  We don't support the 
> format of help output and libvirt shouldn't be using it.  That's been 
> expressed many, many times in the past and libvirt has not stopped using it.

We'd love to use something else, but since the 'something else' doesn't
yet exist we've had no choice but to continue groking the help output. 
The discussion about a formally structure -query-version command is a step
in the right direction here. A similar option for querying supported command
line args would remove the need to rely on -help output.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]