From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Enhance perf to support KVM Date: Fri, 26 Feb 2010 14:54:44 +0200 Message-ID: <4B87C494.4090306@redhat.com> References: <1267068445.1726.25.camel@localhost> <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> <4B87B407.2070309@redhat.com> <20100226124646.GB19476@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20911 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935925Ab0BZMzS (ORCPT ); Fri, 26 Feb 2010 07:55:18 -0500 In-Reply-To: <20100226124646.GB19476@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 02:46 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> You basically have given up control over the quality of KVM by pushing so >>> many aspects of it to user-space and letting it rot there. >>> >> That's wrong on so many levels. First, nothing is rotting in userspace, >> qemu is evolving faster than kvm is. If I pushed it into the kernel then >> development pace would be much slower (since kernel development is harder), >> quality would be lower (less infrastructure, any bug is a host crash or >> security issue), and I personally would be totally swamped. >> > That was not what i suggested tho. tools/kvm/ would work plenty fine. > I'll wait until we have tools/libc and tools/X. After all, they affect a lot more people and are concerned with a lot more kernel/user interfaces than kvm. > As i said: > > >>> [...] You are pushing _way_ too much to user-space into different modules >>> and maintenance domains, [...] >>> >>> ( Note that i dont mind user-space tooling per se, as long as it sits together >>> with the kernel bits and gets developed, packaged and given to the user >>> in the same domain. ) [...] >>> > > >>> Sure the design looks somewhat cleaner on paper, but if the end result is >>> not helped by it then over-modularization sure can hurt ... >>> >> Run 'rpm -qa' one of these days. Modern software is modular, that's the >> only way to manage it. >> > Of course rpm -qa shows cases where modularization works. But my point was > over-modularization, which due to the KVM/qemu split we all suffer from. > You're the only one who suffers from it. Everyone else is happy with adding features in the modules that implements them, be it kvm, qemu, libvirt, or virt-manager (to name one tool stack out of several). > Modularizing along the wrong interface is worse than not modularizing > something that could be. So when designing software you generally want to err > on the side of _under_-modularizing. It's always very easy to split stuff up, > when there's a really strong technical argument for it. It's very hard to pull > the broken pieces back together though once they are in difference domains of > maintanence - as then it's usually social integration that has to happen, > which is always harder than a technical split-up. > As it happens, the kvm and qemu development community has a large overlap. Many developers read both lists, contribute to both projects, and participate on the same weekly call. While we had difficulties pushing patches to qemu in the past, that's behind us, and qemu is now accepting patches at a much higher rate than kvm. Technically, it is obvious that the userspace and kernel components are separate projects. All that remains is the social divide. Since everyone (except you) is mostly happy, I see no reason to change. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.