[Top][All Lists]

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

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

From: Avi Kivity
Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Date: Thu, 29 Dec 2011 19:26:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/29/2011 07:22 PM, Peter Maydell wrote:
> On 29 December 2011 16:36, Avi Kivity <address@hidden> wrote:
> > Yes; but using Linux limits you to what it exposes (of course Linux
> > exposes quite a lot, so that's mostly a non issue; but we'll have
> > counterexamples).
> Actually IME Linux is pretty conservative about how it uses devices.
> A lot of the ARM device models have gaping holes in their emulation
> which we've never needed to fix because Linux simply doesn't use
> those features (eg the PL080 DMA controller which doesn't actually
> implement DMA!)

We were discussing fingerprinting, not actually driving the device.  For
that, I think we're all agreed that qtest is vastly superior to using an
OS driver.

> I think for devices what would be particularly useful would be
> if you can write a (simple) test for something at the register
> level, which generates an image which you can run on the real
> hardware as well as on QEMU. Then you can confirm that your test
> case is correct. Otherwise the tests are just going to bake in the
> same assumptions/misconceptions about what the hardware does as
> the QEMU model.

That is exactly qtest.

> My guess is that a serious attempt at tests covering all the
> functionality of a device is probably approximately doubling
> the effort required for a device model, incidentally. A
> half-hearted attempt probably doesn't buy you much over
> automating "boot the guest OS and prod its driver".


error compiling committee.c: too many arguments to function

reply via email to

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