qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] add "make check"


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] add "make check"
Date: Tue, 25 Oct 2011 10:03:07 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 10/25/2011 07:21 AM, Kevin Wolf wrote:
Am 24.10.2011 20:57, schrieb Anthony Liguori:
On 10/24/2011 01:43 PM, Eduardo Habkost wrote:
On Mon, Sep 05, 2011 at 09:55:20AM +0200, Markus Armbruster wrote:
Gerd Hoffmann<address@hidden>   writes:

    Hi,

This patch series intends to make unit testing easier.  It adds a new
"make check" target which can be used to run all unit tests which are
currently in the tree.  It also enables the unit tests by default, so
you don't have to re-run configure with a special switch.

Reviewed-by: Markus Armbruster<address@hidden>

One test fails, but Luiz has a fix in his tree.

Reviewed-by: Eduardo Habkost<address@hidden>

Now all tests are passing. Why this was not applied yet?

I was hoping for more, but maybe we just need to start here and grow
organically, I'll queue it again.

A while ago I played with some simple IDE tests. It basically was a
small x86 kernel with an empty image that sends IDE commands and prints
some results, and a script that invokes the guest and checks whether the
test has passed or failed.

So at first I started with my own multiboot kernel and copied over some
parts of kvm-unittest's libc. Clearly not the best idea once it's more
than a couple of lines, so at some point I took the code and integrated
with my real kvm-unittests repository.

I did something very similar. I just added PCI support to kvm-unittests such that I could write a small virtio driver.

I actually do think tests like this could live in a make check framework in 
QEMU.

Regards,

Anthony Liguori


Now I don't have to duplicate code any more, but at the same time
there's no chance that a 'make check' in an upstream qemu tree could run
this. Tests for other devices will have exactly the same problem.

Any suggestions on how to go forward with this kind of tests? Should
this go into qemu or into kvm-unittests? Or should kvm-unittests be
merged into the qemu tree? Or is the approach completely wrong?

Kevin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]