From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhHbr-0007Cz-4C for qemu-devel@nongnu.org; Sun, 01 Jan 2012 04:21:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhHbq-0000sN-0G for qemu-devel@nongnu.org; Sun, 01 Jan 2012 04:21:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhHbp-0000sJ-Py for qemu-devel@nongnu.org; Sun, 01 Jan 2012 04:21:41 -0500 Message-ID: <4F00259C.8050303@redhat.com> Date: Sun, 01 Jan 2012 11:21:32 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EEF70B4.3070109@us.ibm.com> <4EF73EF5.8050606@redhat.com> <4EF88EC0.8020301@codemonkey.ws> <4EF8FC88.70809@redhat.com> <4EFA4829.4000207@redhat.com> <4EFA80EA.3050405@codemonkey.ws> <4EFAA2A2.4000107@redhat.com> <4EFB2764.7040006@codemonkey.ws> <4EFB2F36.2090408@redhat.com> <4EFB35AB.6040003@redhat.com> <4EFB4757.4020504@codemonkey.ws> <4EFB5138.5020502@redhat.com> <4EFC916E.4070902@codemonkey.ws> <4EFC9706.4090500@redhat.com> <4EFCA2AF.5000806@redhat.com> <4EFCA9E6.3090706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "lmr@redhat.com" , Stefan Hajnoczi , cleber@redhat.com, dlaor@redhat.com, qemu-devel , Gerd Hoffmann , Cleber Rosa On 12/29/2011 11:10 PM, Peter Maydell wrote: > > > Even if that turns out to be the case, it's fine. Better to > > have a few good devices than dozens of bad ones. > > This is easier to say on the x86 side of the fence, since > most of the devices you need are already in the codebase and > nobody is going to throw them out again if tests don't get > written for them :-) > > There are lots of things where I'd rather have a "tested by > booting a guest OS" implementation than none at all (like audio > support for the versatile/etc boards, which went in recently) or > TrustZone support (not in yet but may be along later). At least > then we have something that works for most people and something > we can fix bugs in, rather than a gaping hole in capability. > We can have different criteria for different parts of the tree. Undesirable, but tradeoffs have to be made. -- error compiling committee.c: too many arguments to function