From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42514 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pmkzx-00005B-5N for qemu-devel@nongnu.org; Tue, 08 Feb 2011 05:40:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pmkzw-00084L-2G for qemu-devel@nongnu.org; Tue, 08 Feb 2011 05:40:40 -0500 Received: from david.siemens.de ([192.35.17.14]:19573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pmkzv-00083U-NE for qemu-devel@nongnu.org; Tue, 08 Feb 2011 05:40:40 -0500 Message-ID: <4D511D8F.5070008@siemens.com> Date: Tue, 08 Feb 2011 11:40:15 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default References: <4D3DFD20.8060004@linux.vnet.ibm.com> <20110125091741.GB30239@edde.se.axis.com> <20110125133453.GC5427@amt.cnet> <20110207101255.GA20413@amt.cnet> <20110207160350.GA26332@amt.cnet> <4D501C71.7090708@redhat.com> <4D50279B.5010102@siemens.com> <4D505DCB.9050406@codemonkey.ws> <20110207214551.GB16429@hall.aurel32.net> <4D50A5F0.802@codemonkey.ws> <20110208072657.GD16429@hall.aurel32.net> <4D50FA14.5010100@redhat.com> <4D5103E8.6050808@siemens.com> <4D510771.3040309@aurel32.net> <4D511221.9030505@siemens.com> <4D5113D3.9090802@aurel32.net> <4D511500.1040303@siemens.com> <4D5115C2.6060008@aurel32.net> <4D511AAF.7040202@aurel32.net> In-Reply-To: <4D511AAF.7040202@aurel32.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Anthony Liguori , Stefan Hajnoczi , Stefan Hajnoczi , Marcelo Tosatti , "qemu-devel@nongnu.org" , Anthony Liguori , Paul Brook , Paolo Bonzini , "Edgar E. Iglesias" , Arun Bharadwaj On 2011-02-08 11:27, Aurelien Jarno wrote: > Stefan Hajnoczi a =E9crit : >> Introducing IOTHREAD made !CONFIG_IOTHREAD platforms second class >> citizens. I think you'd like people to provide full support when they >> introduce new features. >> >=20 > I think you really pointed the problem here. We should probably add a > feature that will make KVM second class citizen so that people can > understand what it means. There are people out there who already thought loudly about forking or rewriting those QEMU bits required for KVM support just to make "life easier". I already disagreed on this, and I continue to do so as both use cases nicely benefit from each other. KVM is driving QEMU features today that would otherwise have taken years to show up, if at all. On the other side, all those bits related to the cross-arch platform emulation of non-x86 helps and will continue to help KVM support on those archs as well (we already have it on PPC, we'll see on ARM and likely more in the future). So, please let's stop this useless finger pointing, on both sides. KVM and QEMU is a symbiosis. Unfortunately, this is not (yet?) the case for POSIX vs. Windows hosts. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux