From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVUGC-00061t-JD for qemu-devel@nongnu.org; Fri, 06 Feb 2009 12:13:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVUGA-000606-L3 for qemu-devel@nongnu.org; Fri, 06 Feb 2009 12:13:00 -0500 Received: from [199.232.76.173] (port=59489 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVUGA-0005zn-CE for qemu-devel@nongnu.org; Fri, 06 Feb 2009 12:12:58 -0500 Received: from yx-out-1718.google.com ([74.125.44.152]:20373) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVUGA-0004To-3u for qemu-devel@nongnu.org; Fri, 06 Feb 2009 12:12:58 -0500 Received: by yx-out-1718.google.com with SMTP id 3so415204yxi.82 for ; Fri, 06 Feb 2009 09:12:57 -0800 (PST) Message-ID: <498C6F83.9010404@codemonkey.ws> Date: Fri, 06 Feb 2009 11:12:35 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Cutting a new QEMU release References: <1233825194.6637.4.camel@ecrins.fosdick.home.net> <498AF6FC.90803@codemonkey.ws> <200902050936.49909.rickv@hobi.com> <200902051627.21972.paul@codesourcery.com> <498B380E.5090603@codemonkey.ws> <1233917676.6637.39.camel@ecrins.fosdick.home.net> <498C5DCC.3060106@exactcode.de> In-Reply-To: <498C5DCC.3060106@exactcode.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org René Rebe wrote: > > Hi, >> > Indeed. Though I used KVM for the past months to do Linux development > and system testing / integration I had a use case for kqemu (non-VT CPU) > just this week and was surprised to find quite "old" kqemu release > just build > and work for booth 2.6.26 and 2.6.28. And so far there was no problem > with > it. > > While I have no problem having it long time ported to the KVM interface, > just declaring some quite useful and functional piece of open source work > obsolete and unsupported quite drastic. This work should be not be lost > so easily. I think you misunderstand. Noone is claiming that kqemu is no longer being supported. Quite rather, we're simply stating it's never been supported. It started as a binary kernel module, impossible to support within the QEMU community. While Fabrice has open sourced kqemu, it's never been included in QEMU. It's not maintained by the current QEMU maintainers and not supported by the current QEMU maintainers. It's essentially a separate project. Regards, Anthony Liguori > When kqemu is supposed to be gotten upstream the question remains what > to do with the freebsd, windows, solaris, etc. glue code. > > If I would know more of the internals of kqemu I would even volunteer to > maintain it - however, I just took the first look at it yesterday > which does > not really qualify to maintain it just yet. Though I would work on > getting > it adapted on future kernel changes, and/or even hunt a bug if it starts > crashing in one or another scenario for me (but right now I have to hunt > some crashing with 32bit host KVM for a start). > > Yours, >