On Fri, Aug 07, 2015 at 03:27:29PM +0300, Pavel Fedin wrote:
Hello!The qemuxml2argvtest mocks the capability cache, so it must be qemuxml2xmltest. And that one should do *nothing* with any capabilities. Merely because whatever it does must work without any qemu installed in the system.This is what happens if you remove the check: --- cut --- ../build-aux/test-driver: line 107: 21055 Segmentation fault "$@" > $log_file 2>&1 FAIL: qemuxml2argvtest ../build-aux/test-driver: line 107: 21081 Segmentation fault "$@" > $log_file 2>&1 FAIL: qemuxml2xmltest ../build-aux/test-driver: line 107: 21107 Segmentation fault "$@" > $log_file 2>&1 FAIL: qemuxmlnstest ../build-aux/test-driver: line 107: 21133 Segmentation fault "$@" > $log_file 2>&1 FAIL: qemuargv2xmltest PASS: qemuhelptest ../build-aux/test-driver: line 107: 21185 Segmentation fault "$@" > $log_file 2>&1 FAIL: domainsnapshotxml2xmltest --- cut ---
Of course, because there are no capabilities when defining XML, capabilities are per emulator binary and that is not known until you are starting the machine (it can change between define and start just by updating qemu for example).
Moreover the test might produce different results for different QEMU binaries installed in the system, which is even worse.Really? As far as i understand the code capabilities are not retrieved from the actual qemu. They are hardcoded as a set in tests. But, i can miss something because i haven't studied the code well.
They are, but only in qemuxml2argvtest and apparently only when creating the command-line. Because parsing the XML should be unambiguous and indifferent to the qemu binary that's in the system. Martin
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
