From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43132 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsHay-0005OF-Ic for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:57:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OsHax-0000mV-8f for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:57:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39972) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OsHax-0000mP-1D for qemu-devel@nongnu.org; Sun, 05 Sep 2010 11:57:27 -0400 Message-ID: <4C83BDE2.8050608@redhat.com> Date: Sun, 05 Sep 2010 18:57:22 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Unmaintained QEMU builds References: <4C62825A.6000903@mail.berlios.de> <4C685F5D.2090707@codemonkey.ws> <4C69A29F.5000606@codemonkey.ws> <4C6AE96C.2040907@codemonkey.ws> <4C837CAF.4080200@redhat.com> <4C83A679.7060907@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Blue Swirl , QEMU Developers On 09/05/2010 06:44 PM, Andreas F=E4rber wrote: > Am 05.09.2010 um 16:17 schrieb Avi Kivity: > >> On 09/05/2010 05:10 PM, Blue Swirl wrote: >>> Easy to use GUI and integration to host system are important, but >>> performance is also a big problem. QEMU/TCG can't compete with >>> alternatives that use proprietary kernel modules. Someone should >>> recreate kqemu by using KVM compatible interfaces. >> >> If someone is really willing to invest the effort to do that cleanly,=20 >> I am willing to merge it into kvm. That would allow reuse of the mmu=20 >> and some other logic that got a lot of effort in kvm. > > I believe I already inquired about this when kqemu was dropped: KVM is=20 > GPL'ed iiuc. May we use it as a kernel extension with proprietary Mac=20 > OS X at all then?=20 No idea. > I thought there was some controversy on whether runtime-linking GPL=20 > modules to a closed-source kernel constitutes a GPL violation or not.=20 > (it would be news to me if Darwin/x86 was ever supported by kqemu) > Having kqemu running as a userland service process (?) on Windows=20 > seems unproblematic by comparison. These things want to run in the kernel (or did you mean a kernel driver=20 providing services to userland?) > Don't know about the BSDs or how this would fit with OpenSolaris'=20 > CDDL. On Haiku new kernel code would probably be preferred under=20 > MIT/X11 License. > > In either case, I'm not aware of a clear documentation of what exactly=20 > is required to implement on the kernel side to replace kqemu or to=20 > provide a completely compatible implementation. It seems like a moving=20 > target. You can pick any recent snapshot and implement its interface. We don't=20 force to upgrade their kernel as we go along. >> However, I doubt it is worth the effort, if anyone is interested in=20 >> performance then they'd get a cpu that supports virtualization. >> >> That leaves non-Linux. > > This discussion was about non-Linux only. We can hardly call the Linux=20 > build unmaintained! :) Yeah - I though it diverged to whether we ship a bundled GUI or not -=20 without that, performance doesn't really matter for non-Linux. --=20 error compiling committee.c: too many arguments to function