From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V52zO-0001r5-OB for qemu-devel@nongnu.org; Thu, 01 Aug 2013 20:13:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V52u9-0005Af-0B for qemu-devel@nongnu.org; Thu, 01 Aug 2013 20:07:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60888 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4tXM-00061F-H4 for qemu-devel@nongnu.org; Thu, 01 Aug 2013 10:07:28 -0400 Message-ID: <51FA6B9A.7030209@suse.de> Date: Thu, 01 Aug 2013 16:07:22 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1375258430-2120-1-git-send-email-v.maffione@gmail.com> <51F8DF58.4030104@suse.de> <20130731112024.GD28592@stefanha-thinkpad.muc.redhat.com> <20130801093856.GC29838@stefanha-thinkpad.redhat.com> In-Reply-To: <20130801093856.GC29838@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v5 0/2] e1000: add interrupt mitigation support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , "Michael S. Tsirkin" , lersek@redhat.com, Jason Wang , qemu-devel@nongnu.org, Vincenzo Maffione , Stefan Hajnoczi , Paolo Bonzini , Giuseppe Lettieri , Luigi Rizzo Am 01.08.2013 11:38, schrieb Stefan Hajnoczi: > On Wed, Jul 31, 2013 at 03:39:05PM +0200, Vincenzo Maffione wrote: >> Ok, but it's unclear how do you prefer to create and "empty" >> PC_COMPAT_1_6 in Patch 1. >> If you want to keep this declaration form >> >> [...] >> .compat_props =3D (GlobalProperty[]) { >> PC_COMPAT_1_6, >> { /* end of list */ } >> }, >> [...] >> >> in the two pc_*_machine_v1_6 structs, I'm forced to define >> >> #define PC_COMPAT_1_6 { /*empty*/ } >> >> but then I can't extend PC_COMPAT_1_5 with PC_COMPAT_1_6 as "header" >> (like you guys do for PC_COMPAT_1_5 and PC_COMPAT_1_4), because >> otherwise PC_COMPAT_1_6 would act as a premature terminator for >> PC_COMPAT_1_5 (right?). >> >> Should I extend PC_COMPAT_1_5 with PC_COMPAT_1_6 as a "tail", or >> should I avoid extending it in the Patch 1, and do the extension in >> Patch 2 (when I have a non-empty PC_COMPAT_1_6)? >=20 > You are right, (GlobalProperty[]) {, {...}} is not valid syntax. In > that case I would switch PC_COMPAT_1_6 into the e1000 interrupt > mitigation patch. That way the patches are bisectable. >=20 > You can still introduce the QEMU 1.7 pc machine type as a separate > patch if you wish, but I no longer see a big win if PC_COMPAT_1_6 canno= t > be isolated from the e1000 change. >=20 > Andreas: Do you agree to do everything in a single patch? I see now that it wouldn't work with an empty macro (unless we drop the ",{}" and then later have to remember to add it back, which may be even worse; my main concern was having the property set in the actual patch for bisecting and cherry-picking, so no objections from my side. mst was the other candidate for needing compat_props for now-delayed ACPI= . Stefan, you haven't replied wrt VMXNET3 and MSI-X yet - that may be another candidate if we can't break migration format as proposed. But we can always introduce the same machine in several patches, we just need to be careful with merging them to not get multiple 1.7 machines and not to loose properties. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg