From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgKpf-0007Eu-6E for qemu-devel@nongnu.org; Thu, 29 Dec 2011 13:36:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgKpe-0000f3-4j for qemu-devel@nongnu.org; Thu, 29 Dec 2011 13:36:03 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:45171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgKpd-0000ez-VM for qemu-devel@nongnu.org; Thu, 29 Dec 2011 13:36:02 -0500 Received: by yhgg71 with SMTP id g71so9715542yhg.4 for ; Thu, 29 Dec 2011 10:36:01 -0800 (PST) Message-ID: <4EFCB30E.9030002@codemonkey.ws> Date: Thu, 29 Dec 2011 12:35:58 -0600 From: Anthony Liguori 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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 , Avi Kivity , Cleber Rosa , Gerd Hoffmann On 12/29/2011 11:49 AM, Peter Maydell wrote: > On 29 December 2011 17:26, Avi Kivity wrote: >> On 12/29/2011 07:22 PM, Peter Maydell wrote: >>> 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". >> >> Agreed. > > The next obvious question is: are we going to make a serious attempt? > (For instance, in a hypothetical tests-required world, would we > tell those nice folks from Samsung "no you can't land your > Exynos patches unless you write 9000+ lines of test cases" ? The virtio-serial test case I posted was 50 lines in qemu-test. The virtio-serial driver is about ~1500 LOC. That's about 3%. I would expect that we at least have some sort of test that could verify that the Exynos platform more or less worked as expected. If that was just booting a Linux kernel, that would be fine by me. > I suspect that if we set the bar for new board and device models > that high then the result will largely be that we don't in fact > get new board or device models.) This is why the barrier needs to be as low as possible. Regards, Anthony Liguori > -- PMM >