[libvirt] [PATCH v1 6/7] tests: Update qemucapabilitiesdata
Michal Privoznik
mprivozn at redhat.com
Tue Apr 17 08:52:40 UTC 2018
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 at 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.
Michal
More information about the libvir-list
mailing list