From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6134-0007sZ-8H for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:44:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6132-0005yA-1q for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:44:01 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:43409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6131-0005wc-Rz for qemu-devel@nongnu.org; Fri, 09 Mar 2012 09:43:59 -0500 Received: by dadp14 with SMTP id p14so1729604dad.4 for ; Fri, 09 Mar 2012 06:43:57 -0800 (PST) Message-ID: <4F5A1729.5060206@codemonkey.ws> Date: Fri, 09 Mar 2012 08:43:53 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F582EDB.1040608@redhat.com> <4F58B5CB.8040503@codemonkey.ws> <4F58CDEA.2020506@redhat.com> <4F59010C.2060105@codemonkey.ws> <4F5909B3.4080405@redhat.com> <4F590BD7.6030605@codemonkey.ws> <4F5913F3.3040503@redhat.com> <4F591EB4.1090300@codemonkey.ws> <4F5A076E.9040904@redhat.com> <4F5A0D49.60200@codemonkey.ws> <4F5A13FA.6040606@redhat.com> In-Reply-To: <4F5A13FA.6040606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Lucas Meneghel Rodrigues , Cleber Rosa , QEMU devel , Ademar Reis On 03/09/2012 08:30 AM, Paolo Bonzini wrote: > Il 09/03/2012 15:01, Anthony Liguori ha scritto: >>> How do you handle out-of-tree patches with submodules (as is the case >>> when working on new code)? >> >> It's very easy to update .gitmodules to point to a different tree on >> your local system and then update the ref to a local commit. >> >> So from a development perspective, it's simple. The harder question is >> what to do about qemu-test HEAD on qemu.org > > Yep. So you would commit patches to qemu.git with some kind of IOU for > tests, that will be committed as soon as kernel support hits the mainline? Probably commit the test and mark it as an expected failure until support hits mainline. > >>> You want to require tests in order to commit to qemu, but this (for >>> tests where using qtest is not feasible for any reason) requires all >>> drivers to be upstream and accessible to qemu-jeos. >> >> We're really just talking about virtio here, no? Maybe we can convince >> Rusty to have a proper virtio-next.git... >> >> I think this ends up being outside the scope of qemu-test. Perfect is >> the enemy of good here. > > No, this ends up being outside the scope of Anthony, who only cares > about testing KVM/x86. We add one virtio device every couple years, > while new ARM boards are added every couple months. It kind of works > because a large part of the QEMU development community is testing on > KVM/x86, but not entirely. qemu-test is a specific solution to a specific problem. The problem is: how can you leverage an existing kernel to simplify writing device model tests without having a full blown libOS in qtest. Linux is the only part that matters here. The userspace in qemu-jeos is just there to give a small environment for Linux to function properly in. > It is not a problem. of course: you're human, you're one person and one > would need a dozen to set up everything properly. OTOH, it's too easy > to dismiss buildroot when you are catering to a much smaller objective. > The complete objective would have a much bigger overlap with > buildroot's, and likely the design would too. You have a different objective than I do. You want to build a reproducible guest that runs on a wider variety of architectures than common distributions do with a good enough userspace to write integration tests with. That's a good goal if you care about the full stack. I'm skeptical of the value of this from a QEMU point of view. Do we really care if the buildroot version of udev propagates hotplug events correct in buildroot for ARM in a beagleboard machine? I'm sure someone cares about that, but it's ultimately not a QEMU problem. I think we need to focus on getting our house in order (in terms of quality) before we start trying to tackle a larger scope. Regards, Anthony Liguori > > Paolo