On 11/06/2017 08:26 AM, Andrea Bolognani wrote:
The architecture itself is called ppc64, and it can run both in big endian and little endian mode - the latter is known as ppc64le.
From the (virtual) hardware point of view, ppc64 is a more accurate name so it should be used here.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- .../{qemu_2.6.0.ppc64le.xml => qemu_2.6.0.ppc64.xml} | 2 +- tests/domaincapstest.c | 2 +- .../{caps_2.6.0.ppc64le.replies => caps_2.6.0.ppc64.replies} | 0 .../{caps_2.6.0.ppc64le.xml => caps_2.6.0.ppc64.xml} | 0 .../{caps_2.9.0.ppc64le.replies => caps_2.9.0.ppc64.replies} | 0 .../{caps_2.9.0.ppc64le.xml => caps_2.9.0.ppc64.xml} | 0 tests/qemucapabilitiestest.c | 4 ++-- 7 files changed, 4 insertions(+), 4 deletions(-) rename tests/domaincapsschemadata/{qemu_2.6.0.ppc64le.xml => qemu_2.6.0.ppc64.xml} (98%) rename tests/qemucapabilitiesdata/{caps_2.6.0.ppc64le.replies => caps_2.6.0.ppc64.replies} (100%) rename tests/qemucapabilitiesdata/{caps_2.6.0.ppc64le.xml => caps_2.6.0.ppc64.xml} (100%) rename tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.replies => caps_2.9.0.ppc64.replies} (100%) rename tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.xml => caps_2.9.0.ppc64.xml} (100%)
So this is just for our tests right? I guess I see a name change like this and I think - is there some sort of migrate or save/restore issue we could have by changing the "name"... Anyway - I see the the "ppc64" matches the JSON return: { "return": { "arch": "ppc64" }, "id": "libvirt-3" } So, close my eyes and hope it all works ;-) Reviewed-by: John Ferlan <jferlan@redhat.com> John