From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBadJ-0002hh-SV for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:30:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBadE-0002bA-R8 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:30:53 -0400 Received: from [199.232.76.173] (port=60129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBadE-0002ak-9C for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:30:48 -0400 Received: from mx20.gnu.org ([199.232.41.8]:64949) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBadD-00043f-T3 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:30:48 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBadC-0004xj-Ay for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:30:46 -0400 From: Paul Brook Date: Tue, 2 Jun 2009 21:30:42 +0100 References: <20090602035217.GA16574@foursquare.net> <200906021354.31637.paul@codesourcery.com> <20090602200918.GA27850@foursquare.net> In-Reply-To: <20090602200918.GA27850@foursquare.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906022130.42639.paul@codesourcery.com> Subject: [Qemu-devel] Re: Killing KQEMU List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Frey Cc: qemu-devel@nongnu.org >> 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) > >These are fairly small annoyances, no? I'm assuming they are, since they >exist at all, considering the frustration evident in: They're horrid hacks that I only reluctantly created in the first place. Limiting guest physical memory to 4G is a fairly serous issue. Requiring the user specify how much ram they require upfront will not be acceptable once we have machine config files. >> 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. > >I would hope that anyone who deliberately breaks kqemu support would be >kind enough to post that fact to the mailing list Sure, but this is actually part of my point. If noone cares enough to track+test the development branch, then it just proves how little anyone actually cares about kqemu. > > 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. > > According to other threads on this list, it would appear that getting > KQEMU into the kernel is often thought of as impossible, or "would never > happen." In its current form that's probably true. It may effectively require a complete rewrite. OTOH kqemu has some fairly serious bugs, and may need a complete rewrite to fix those bugs. IMHO current kqemu is effectively unsupportable[1] for any serious use, which is one of the reasons I'm not concerned about it going away in the near future. Paul [1] Unsupportable == I'm not letting it anywhere near my production systems. When it breaks you keep both pieces, and it's unlikely anyone knows how to glue them back together again.