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