From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: KVM usability Date: Sat, 27 Feb 2010 18:25:46 +0100 Message-ID: <20100227172546.GA31472@elte.hu> References: <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> <4B893B2B.40301@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Zachary Amsden Return-path: Received: from mx3.mail.elte.hu ([157.181.1.138]:51673 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030205Ab0B0R0G (ORCPT ); Sat, 27 Feb 2010 12:26:06 -0500 Content-Disposition: inline In-Reply-To: <4B893B2B.40301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Zachary Amsden wrote: [...] > > Second, it's not over-modularized. The modules are the individual > components of the architecture. How would you propose to put it > differently. They really can't naturally combine. And with the > code quality of qemu in general being problematic by Linux kernel > standards, it's not natural to move the device emulation directly > into the kernel module. So this is why we are where we are today. I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. It would be a no-brainer: most of the devs come from the KVM side, and KVM itself makes little sense without Qemu, and Qemu makes little sense without KVM these days. (and i know about the non-KVM and non-x86 roots of Qemu - still, it's not a significant piece of usage today) > Third, it's the maintainers upstream who are in charge of KVM > quality as a whole - when you are talking about upstream code > quality, and the package maintainers who are in charge of KVM > quality as a whole - when you are talking about a distro. This is > nothing new - it's just a statement of decentralization. It's certainly nothing new. Nor was the suckage of CVS newup until Git came along and changed the game on a fundamental basis. Suckage is there to be fought all the time. Ingo