From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3CzK-0005yV-3v for qemu-devel@nongnu.org; Mon, 12 Sep 2011 16:20:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3CzI-000682-RZ for qemu-devel@nongnu.org; Mon, 12 Sep 2011 16:20:18 -0400 Message-ID: <4E6E697B.1060002@redhat.com> Date: Mon, 12 Sep 2011 17:20:11 -0300 From: Lucas Meneghel Rodrigues MIME-Version: 1.0 References: <1315500885-32577-1-git-send-email-agraf@suse.de> <4E6C9068.50508@redhat.com> <4E6DCBDC.8040002@redhat.com> <4E6E0D41.9010902@redhat.com> <4E6E0ED6.9060507@redhat.com> In-Reply-To: <4E6E0ED6.9060507@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] PPC: Fix via-cuda memory registration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "qemu-ppc@nongnu.org" , Alexander Graf , qemu-devel Developers On 09/12/2011 10:53 AM, Avi Kivity wrote: > On 09/12/2011 04:46 PM, Lucas Meneghel Rodrigues wrote: >> Yes, that would also work, having different variants with different >> qemu and qemu-img paths. Those binaries would have to be already >> pre-built, but then we miss the ability autotest has of building the >> binaries and prepare the environment. It'd be like: >> >> variant1: >> qemu = /path/to/qemu1 >> qemu-img = /path/to/qemu-img1 >> extra_params = "--appropriate --extra --params2" >> >> >> variant2: >> qemu = /path/to/qemu2 >> qemu-img = /path/to/qemu-img2 >> extra_params = "--appropriate --extra --params2" >> >> Something like that. It's a feasible intermediate solution until I >> finish work on supporting multiple userspaces. >> > > Another option is, now that the binary name 'qemu' is available for > general use, make it possible to invoke everything with just one binary: > > qemu -system -target mips ... > qemu-system -target mips ... > qemu-system-mips ... > > are all equivalent. autotest should easily be able to pass different > -target based on the test being run. Indeed, a good idea, although there are cases where we indeed want to run different user spaces (say, a windows reactivation test for example), so it's still worth to implement the multiple userspaces thing for autotest. But in the case we just want to run multiple targets, this would be very handy indeed.