Ok, so back to the one-patch version! :) I'll prepare it asap.
Thanks,
Vincenzo
2013/8/1 Andreas Färber <afaer...@suse.de>:
> 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 = (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)?
>>
>> 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.
>>
>> 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 cannot
>> be isolated from the e1000 change.
>>
>> 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
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
Vincenzo Maffione
