[libvirt] [PATCH v2 8/9] tests: Use qemuProcessPrepareMonitorChr in qemuxmlnstest

Daniel P. Berrange berrange at redhat.com
Mon Aug 24 09:58:08 UTC 2015


On Mon, Aug 24, 2015 at 11:50:13AM +0200, Martin Kletzander wrote:
> On Mon, Aug 24, 2015 at 10:32:43AM +0100, Daniel P. Berrange wrote:
> >On Mon, Aug 17, 2015 at 12:16:49PM -0700, Martin Kletzander wrote:
> >>The output of that function was not tested until now.  In order to keep
> >>the paths in /tmp, the test driver config is "fixed" as well.
> >>
> >>Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> >>---
> >> .../qemuxmlns-qemu-ns-commandline-ns0.args            |  2 +-
> >> .../qemuxmlns-qemu-ns-commandline-ns1.args            |  2 +-
> >> .../qemuxmlnsdata/qemuxmlns-qemu-ns-commandline.args  |  2 +-
> >> .../qemuxmlns-qemu-ns-domain-commandline-ns0.args     |  2 +-
> >> .../qemuxmlns-qemu-ns-domain-commandline.args         |  2 +-
> >> tests/qemuxmlnsdata/qemuxmlns-qemu-ns-domain-ns0.args |  2 +-
> >> tests/qemuxmlnsdata/qemuxmlns-qemu-ns-domain.args     |  2 +-
> >> tests/qemuxmlnstest.c                                 | 19 +++++++++++++------
> >> 8 files changed, 20 insertions(+), 13 deletions(-)
> >
> >ACK
> >
> 
> Thanks for the review, should I keep it as a separate patch or squash
> it into the previous one (I prefer the former)?  How about the
> qemuxml2argvtest, do we want to modify that as well if the function is
> already being tested here?  I'm referring to the original question in
> the cover letter.

Squash it if it is needed to ensure git bisect succeeds.

I don't really mind either way about the qemuxml2argvtest - it is
sufficient to have the codepath tested by qemuxmlnstest IMHO.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list