On Tue, Apr 17, 2018 at 10:52:40 +0200, Michal Privoznik wrote:
On 04/17/2018 10:39 AM, Peter Krempa wrote:
> On Thu, Apr 12, 2018 at 18:39:51 +0200, Michal Privoznik wrote:
>> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
>
> So this really needs to be squashed into the previous commit. Also It
> would help if you'd describe what you are doing since it does not seem
> to be the classic churn from just updating the ordering of
> capabilities.
>
> Also I'd suggest to not add a sign-off to patches which you don't intend
> to push, since the commit hook will save you from doing a mistake.
>
>> ---
>
> [...]
>
>> diff --git a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> index ca98ee14db..bc82624335 100644
>> --- a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> +++ b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> @@ -160,7 +160,7 @@
>> <flag name='isa-serial'/>
>> <version>2001001</version>
>> <kvmVersion>0</kvmVersion>
>> - <microcodeVersion>58992</microcodeVersion>
>> + <microcodeVersion>59147</microcodeVersion>
>
> I think this change is not warranted here. If you regenerated the
> capabilities, you need to make sure that the emulators you use have the
> same config, so that we don't change anything that's not necessary.
>
> There are a few other examples here, e.g. with the cpu flags.
>
> It's a shame though that object-add QMP command is not introspectable
> via the QMP schema. It would quite simplify this series.
>
> NACK to change to data which is not relevant to the capability you are
> introducing.
>
In fact it is. In the tests, microcode version is just the file length
of input .replies file. It doesn't reflect any real microcode version.
Just look at testQemuCaps() from tests/qemucapabilitiestest.c.
Oh ... (hits face with palm).
Also I've noticed that the churn in the cpu flags data looks like just
git wrongly picking how to create the diff.
At any rate, it needs to be squashed to the previous commit.