From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nx3iz-0004Si-4E for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:37:13 -0400 Received: from [140.186.70.92] (port=58879 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nx3ix-0004S4-0j for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:37:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nx3iv-0000fM-C6 for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:37:10 -0400 Received: from mail-pz0-f171.google.com ([209.85.222.171]:33153) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nx3iv-0000f1-7R for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:37:09 -0400 Received: by pzk1 with SMTP id 1so329004pzk.18 for ; Wed, 31 Mar 2010 12:37:08 -0700 (PDT) Message-ID: <4BB3A461.5090101@codemonkey.ws> Date: Wed, 31 Mar 2010 14:37:05 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] vhost: fix features ack References: <20100331182031.GA5200@redhat.com> <4BB393CF.1040700@codemonkey.ws> <20100331153805.03ee142e@redhat.com> <20100331190753.GA6914@redhat.com> <4BB3A183.8000905@codemonkey.ws> <20100331192553.GB3274@redhat.com> In-Reply-To: <20100331192553.GB3274@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org, Luiz Capitulino On 03/31/2010 02:25 PM, Michael S. Tsirkin wrote: > On Wed, Mar 31, 2010 at 02:24:51PM -0500, Anthony Liguori wrote: > >> Long term, I think most of us want to see a single qemu executable >> that works for all architectures and compiling once is an important >> step in that direction. >> > I'm not so sure. It's pretty low on my list of priorities. Most users only need > one target, speed of execution and/or features is likely much more important for them, > and these refactorings make code more generic and harder to extend.s > We ought to have a set of device models that are compiled once, with well defined interfaces that model the actual way the various buses communicate. This should all roll into a generic CPU API. Then we should have a set of CPU implementations with choices including various TCG targets and KVM targets. You can still compile out TCG targets that you don't care about but the key point is to get all of these interfaces correct. This refactoring effort isn't really paying attention to improving interfaces which I think is a bit problematic. Regards, Anthony Liguori