From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: KVM usability Date: Mon, 1 Mar 2010 21:56:20 +0100 Message-ID: <20100301205620.GA26151@elte.hu> References: <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B8813F2.8090208@redhat.com> <20100227105643.GA17425@elte.hu> <4B893B2B.40301@redhat.com> <20100227172546.GA31472@elte.hu> <4B8BEFC7.2040000@redhat.com> <20100301174106.GB2362@ghostprotocols.net> <4B8C0778.8050908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Arnaldo Carvalho de Melo , Avi Kivity , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Gleb Natapov , 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]:34561 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750905Ab0CAU46 (ORCPT ); Mon, 1 Mar 2010 15:56:58 -0500 Content-Disposition: inline In-Reply-To: <4B8C0778.8050908@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Zachary Amsden wrote: > > I guess there is some misunderstanding here, the tools/ directory that > > lives in the kernel _sources_, has no kernel source, its all userspace > > stuff. > > Yeah, no morning coffee :=) > > So instead we are advocating forking qemu into the kernel. That makes even > less sense. It's not sustainable or eco-friendly to either community. Here's our experience with tools/perf/. Hosting the project in the kernel proper helped its quality immensely: - It's much easier to synchronize new features on the kernel side and on the user-space side. The two go hand in hand - they are often implemented in the same patch. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. - Lots of eyeballs and interest. In its mere 8 months of existence tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of new code has been written. - Code quality requirements are that of the kernel's. No muck allowed and it's not hard to explain what kind of code is preferred. - Tool breakage bisection is a breeze: there's never any mismatch between tools/perf and the kernel counterpart. With a separate package we'd have more complex test and bisection scenarios. - Code distribution is easy: it comes with the kernel. This spreads the code far and wide. It's easy for kernel developers to jump in and help out, the latest devel code is always there, a single 'cd tools/perf/; make -j install' command away. - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h, hash.h, list.h, rbtree.h, bitops.h, prefetch.h. etc. In the KVM context this was obviously only a suggestion though. If i were hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has very close ties to kernel-KVM and repo level unification would create various synergies - but you are hacking on it, not me ;-) If i were doing it i'd probably start with a cleaned up and stripped down version of Qemu, to make it eligible for mainline kernel inclusion. Ingo