From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXaUU-0002Mn-4r for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:30:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXaUT-0006O1-0e for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:30:02 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:43720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXaUS-0006Nx-Kz for qemu-devel@nongnu.org; Mon, 05 Dec 2011 10:30:00 -0500 Received: by iakk32 with SMTP id k32so10068120iak.4 for ; Mon, 05 Dec 2011 07:30:00 -0800 (PST) Message-ID: <4EDCE375.3060200@codemonkey.ws> Date: Mon, 05 Dec 2011 09:29:57 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1322765012-3164-1-git-send-email-aliguori@us.ibm.com> <4EDB4584.8020606@redhat.com> In-Reply-To: <4EDB4584.8020606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 0/6] qtest unit test framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: qemu-devel@nongnu.org On 12/04/2011 04:03 AM, Dor Laor wrote: > On 12/01/2011 08:43 PM, Anthony Liguori wrote: >> This series is still pretty rough but I wanted to get an idea of what people >> thought about it before polishing it. >> >> The general idea is outlined in the first test. The main advantage of this >> type of test framework compared to something like kvm-unit-test is that you >> don't need a build environment for what you're trying to test. > > Luckily w/ qemu cpu emulation and few images it can be set once and be there for > ever. > > The advantage of kvm-unit-test is that the code actually does run. So we can > test irq injections, io/mmio in the kernel too, dirty bit tracking and some more > all together. Yup, and kvm-unit-test will always need to exist for that. But we need something that makes it easy to test ARM, PPC, s390, etc so that when we do things like the memory API, it's possible for a developer to do reasonable testing without having to track down 100 different images and tool chains. Regards, Anthony Liguori > >> >> Since your tests also link against the host environment, it potentially makes >> tests much simplier to write (as you aren't reinventing an OS). I think this >> makes this style of test more appropriate for something like QEMU. >> >> Anthony Liguori (6): >> qtest: add test framework >> qtest: add support for target-i386 -M pc >> Add core python test framework >> Add uart test case >> Add RTC test case >> Add C version of rtc-test >> >> Makefile | 4 + >> Makefile.objs | 2 + >> hw/pc.c | 7 +- >> hw/pc_piix.c | 9 +- >> qemu-options.hx | 8 ++ >> qtest.c | 357 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> qtest.h | 37 ++++++ >> qtest.py | 69 +++++++++++ >> rtc-test.c | 201 +++++++++++++++++++++++++++++++ >> rtc-test.py | 105 ++++++++++++++++ >> serial-test.py | 24 ++++ >> vl.c | 8 ++ >> 12 files changed, 827 insertions(+), 4 deletions(-) >> create mode 100644 qtest.c >> create mode 100644 qtest.h >> create mode 100644 qtest.py >> create mode 100644 rtc-test.c >> create mode 100644 rtc-test.py >> create mode 100644 serial-test.py >> > >