From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49347 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCvnN-0007hS-3O for qemu-devel@nongnu.org; Fri, 14 May 2010 10:23:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCvnE-0002cP-CF for qemu-devel@nongnu.org; Fri, 14 May 2010 10:23:20 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:44894) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCvnE-0002cA-76 for qemu-devel@nongnu.org; Fri, 14 May 2010 10:23:12 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4EEJ3RE004199 for ; Fri, 14 May 2010 08:19:03 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o4EEMwOt229146 for ; Fri, 14 May 2010 08:23:01 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4E7Mvvt032586 for ; Fri, 14 May 2010 01:22:57 -0600 Message-ID: <4BED5CBF.8060505@linux.vnet.ibm.com> Date: Fri, 14 May 2010 09:22:55 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...' References: <1273696161-14332-1-git-send-email-crobinso@redhat.com> <4BEB11DD.20601@redhat.com> <4BEB142F.2000002@redhat.com> <4BEBB9C2.3050302@redhat.com> <4BEBF8D1.7060401@redhat.com> <4BEBF9A5.3070507@redhat.com> <4BED4EF9.3090800@linux.vnet.ibm.com> <20100514135426.GJ9282@redhat.com> In-Reply-To: <20100514135426.GJ9282@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Jes Sorensen , clalance@redhat.com, qemu-devel@nongnu.org, Cole Robinson On 05/14/2010 08:54 AM, Daniel P. Berrange wrote: > On Fri, May 14, 2010 at 08:24:09AM -0500, Anthony Liguori wrote: > >> On 05/13/2010 08:07 AM, Jes Sorensen wrote: >> >>> On 05/13/10 15:04, Cole Robinson wrote: >>> >>> >>>> On 05/13/2010 04:35 AM, Jes Sorensen wrote: >>>> >>>> >>>>> On 05/12/10 22:48, Cole Robinson wrote: >>>>> I think rather than 1, it would be better to add a patch to libvirt to >>>>> catch both formats. I know Chris Lalancette already cooked up a patch >>>>> for this. Combined with the 2) patch I just posted, and 3) I think that >>>>> should take care of the problems. >>>>> >>>>> >>>> It doesn't solve the problem for existing libvirt installations. It's >>>> not uncommon for users to track just the latest kvm releases without >>>> upgrading libvirt: any future qemu or kvm release will break every >>>> version of libvirt that exists today. Given that unfortunate case, I >>>> still recommend reverting the 'PC' change at least for long enough for a >>>> few fixed libvirt releases to make it into the wild. >>>> >>>> >>> But that is no different from what we have today. Users who update their >>> qemu and see issues with libvirt can also be asked to update libvirt. I >>> have already had several cases where I needed to do that anyway. >>> >>> I don't like reverting a change like this, just to schedule it to be >>> reapplied again later. >>> >>> >> The problem is, we've been down this road many times before. Every >> time, the libvirt folks say they just need this one change for >> compatibility and keep on using the help output. I understand that >> that's the easiest thing to do so we need to make it easier for them to >> do the right thing (which probably means making it harder to do the >> wrong thing :-)). >> >> So I'm willing to apply this patch but only as part of a larger series >> that eliminates the need for libvirt to parse help output. The >> important question is then, what information is libvirt getting from the >> help output today. >> > The short answer is we extract: > > - QEMU version number > - KVM version number (if present) > - Probe for specific named arguments (-drive, -chardev, -device, > and many many more) > This can be tied to version number, no? > - Probe for named flags (eg cache= option to -drive which appeared > after the initial -drive arg did) > Again, this ought to be able to be tied to version number, no? Regards, Anthony Liguori > Things we use the QEMU/KVM version number for: > > - Track changes in syntax of an existing arg. eg -vnc changed > syntax between 0.8.x and 0.9.0 > - Determine if we can use VNET_HDR flag > - Which migration protocols are available (tcp, unix, exec, fd) > - Whether we can use JSON mode monitor yet > - Override use of -netdev - even though its detected in -help > output for 0.12, we can't use it since there was no equivalent > netdev_add command for hotplug. So we have to blacklist it till > 0.13 > > In the ideal world we'd never do anything based off version number, > everything would have some clear functional capability that could > be queried. We'd then only need to use version to blacklist features > we detect, but can't use for some reason. > > If you want the gory details, the key method is qemudComputeCmdFlag() > in source code at line 1124: > > http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_conf.c;h=5fa8c0aa1867e1f67153d72c5b37ba09157c968e;hb=HEAD > > This is where we detect each feature we care about in -help output > > > Regards, > Daniel >