On 10/28/2011 08:59 PM, Tyler Coumbes wrote:
On Thu, Oct 27, 2011 at 10:25 PM, Eric Blake<eblake@xxxxxxxxxx> wrote:
On 10/24/2011 05:44 PM, Tyler Coumbes wrote:
This patch makes the changes to the generic ethernet interface for
QEMU. Allowing it to be used with sVirt enabled.
src/qemu/qemu_command.c | 79
++++++++++++++++++++++++++++++++++++++++++++--
src/qemu/qemu_command.h | 4 ++
src/qemu/qemu_hotplug.c | 15 +++++++++
src/qemu/qemu_process.c | 13 ++++++++
4 files changed, 107 insertions(+), 4 deletions(-)
I haven't reviewed this one closely yet, but it would help if you added a
test in tests/qemuxml2argvtest.c and a new pair of files in
tests/qemuxml2argvdata/* that exercise the code to prove the new command
line options look sane.
Two questions about creating a test for this code. How do I get the
actual args so I can compare them to my expected args to see what
isn't matching up? VIR_TEST_DEBUG=2 shows me what tests fail but not
any detail about why.
VIR_TEST_DEBUG=1 shows a diff between expected and actual text; I'm not
sure why VIR_TEST_DEBUG=2 wouldn't do the same, without diving into the
test code more.
I think it is because one of the parameters to
qemu is a file descriptor which could change for each run. Is there
some type of wildcard I can use like fd=%. I don't see any other tests
using file descriptors to compare to and am not finding anything in
any documentation I can find.
tests/qemuxml2argvdata/qemuxml2argv-restore-v2-fd.args is an example
file that hard-codes a particular fd, and sets things up so that
qemuxml2argvtest.c passes that hard-coded fd through DO_TEST_FULL, which
in turn passes it through the migrateFd argument of qemuBuildCommandLine.
This may mean that we need to refactor things slightly to make it easier
for testing. One idea is to have normal calls to qemuBuildCommandLine
call through a function pointer that opens a TAP and returns that FD;
whereas running it from the testsuite sets that function pointer to
provide a replacement function that just returns a hard-coded number
rather than opening an fd.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list