On 03/23/2016 11:35 AM, Michal Privoznik wrote:
After 9c17d665fdc5 the tap device for ethernet network type is
automatically precreated before spawning qemu. Problem is, the
qemuxml2argvtest wasn't updated and thus is failing. Because of
all the APIs that new code is calling, I had to mock a lot. Also,
since the tap FDs are labeled separately from the rest of the
devices/files I had to enable NOP security driver for the test
too.
Signed-off-by: Michal Privoznik <[email protected]>
---
--- a/tests/qemuxml2argvmock.c
+++ b/tests/qemuxml2argvmock.c
+}
+
+int
+virCommandRun(virCommandPtr cmd ATTRIBUTE_UNUSED,
+ int *exitstatus)
+{
+ if (exitstatus)
+ *exitstatus = 0;
+
+ return 0;
+}
The problem with mocking virCommandRun is that it is called by the test
infrastructure (virTestRewrapFile(), which is used when regenerating the
test results (VIR_TEST_REGENERATE_OUTPUT=1)).
After this commit that function silently fails, which results in
virFileWriteStr() calling strlen(NULL) and a crash of the test. (Nobody
noticed this before because it's only called if you set
VIR_TEST_REGENERATE_OUTPUT *and* the results of one of the qemuxml2argv
tests has changed).
So what's the most reasonable way to deal with this? I suppose we could
rename virCommandRun to e.g. virCommandRunInternal() which would be
called by a new virCommandRun(), then have virTestRewrapFile() call
virCommandRunInternal() so that it wouldn't get the mocked version. That
seems ugly, inefficient, and hackish, but I can't think of any way that
isn't ugly, inefficient, and hackish...
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
