From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IM1jY-0002Fb-IW for qemu-devel@nongnu.org; Fri, 17 Aug 2007 09:19:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IM1jX-0002Ce-6a for qemu-devel@nongnu.org; Fri, 17 Aug 2007 09:19:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IM1jX-0002CQ-42 for qemu-devel@nongnu.org; Fri, 17 Aug 2007 09:19:23 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IM1jW-0003OE-Ii for qemu-devel@nongnu.org; Fri, 17 Aug 2007 09:19:22 -0400 Received: by ug-out-1314.google.com with SMTP id m2so348495uge for ; Fri, 17 Aug 2007 06:19:21 -0700 (PDT) Message-ID: <46C5A054.3070500@gmail.com> Date: Fri, 17 Aug 2007 15:19:16 +0200 From: Sunil Amitkumar Janki MIME-Version: 1.0 Subject: Re: [Qemu-devel] merging kqemu into mainline kernel? References: <8a6cde920708040926s6e12edd0mc3b469ab741c5653@mail.gmail.com> <23bcb8700708160542m45c3d561q3c1590fcfeea3a09@mail.gmail.com> <46C448DA.70303@gmail.com> <46C46693.1020307@freeshell.org> <46C5984B.3060708@gmail.com> In-Reply-To: <46C5984B.3060708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Cc: "Bill C. Riemers" dragoran wrote: >> It looks like you are right. Apparently the plan is to move the >> acceptance of kernel modules to kernel maintainers. For the most part, >> they only want to accept very cleanly written modules that are likely to >> be integrated into the kernel. Since "kqemu" is viewed as a solution >> only for obsolete hardware, that is not likely to happen. > I am not sure that working on older hardware will keep it out of the > kernel. it adds support for unsupported hardware .... I don't see a > problem here. >> It is a shame >> too, because "kqemu" provides a quality working solution for most of the >> hardware still in use today. >> >> > we should atleast try to get it in ... the "it wont get merged anyway" > attitude isn't very helpfull. I hope the kqemu module could be either updated and merged as it is or its functionality, i.e. not hardware assisted acceleration, integrated into the kvm module (if possible). The latter would be an adequate solution for x86, but what about other architectures? Over the past few months I have added both MIPS and SPARC based systems to my collection and I would like to have some kind of acceleration of guests for those as well, short of recreating VMware for both. The operating system running on all architectures is the same, so why support one over the other? I understand x86 is the dominant architecture for general purpose computing at the moment, but UltraSPARC T1/T2, Loongson, Cell and future IA64 processors are changing all of that. Sunil