From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBTVs-000118-DZ for qemu-devel@nongnu.org; Tue, 02 Jun 2009 08:54:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBTVn-0000wX-88 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 08:54:43 -0400 Received: from [199.232.76.173] (port=46529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBTVn-0000wL-1N for qemu-devel@nongnu.org; Tue, 02 Jun 2009 08:54:39 -0400 Received: from mx20.gnu.org ([199.232.41.8]:31945) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBTVm-0002ex-I9 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 08:54:38 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBTVk-0005Ql-PM for qemu-devel@nongnu.org; Tue, 02 Jun 2009 08:54:37 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Killing KQEMU Date: Tue, 2 Jun 2009 13:54:30 +0100 References: <20090602035217.GA16574@foursquare.net> <200906012345.18729.rickv@hobi.com> In-Reply-To: <200906012345.18729.rickv@hobi.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906021354.31637.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Chris Frey > And to any devs who are eager to rid Qemu of KQemu - first, thanks for Qemu > :-) ... but also, why are you eager to rid Qemu of KQemu? (this is not a > rhetorical question - very sincere question. I'm looking to learn here...) > I understand that KQemu is perhaps sub-optimal in some or many ways, and/or > abandoned. Does keeping the KQemu-supporting bits in Qemu cause some > hindrance in developing other features? osdep.c:/* FIXME: This file should be target independent. However it has kqemu vl.c: /* FIXME: This is a nasty hack because kqemu can't cope with dynamic cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong. */ exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU) If you want kqemu to continue existing, you need to find someone to actively maintain it. IMO at bare minimum all the above need to go away. AFAIK there's not currently anyone has the time/inclination to do this, and from most accounts kqemu doesn't really work very reliably at the best of times. Or let me put it another way: At some point I'll get fed up of the limitations that kqemu currently imposes, and deliberately break it. If it remains broken then it will be removed. You get to decide whether you want to fix kqemu, start again from scratch (probably enhancing KVM), or keep using old versions of qemu. As I've said before, if you're serious about maintaining kqemu you probably need to get it integrated into mainstream kernels. Without this a large portion of the relevant communities simply aren't going to care. Paul