From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM usability Date: Mon, 01 Mar 2010 15:45:06 -0600 Message-ID: <4B8C3562.30900@codemonkey.ws> 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> <20100301205620.GA26151@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Zachary Amsden , Arnaldo Carvalho de Melo , Avi Kivity , "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: Ingo Molnar Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:56038 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752109Ab0CAVpN (ORCPT ); Mon, 1 Mar 2010 16:45:13 -0500 Received: by gyh20 with SMTP id 20so1376606gyh.19 for ; Mon, 01 Mar 2010 13:45:12 -0800 (PST) In-Reply-To: <20100301205620.GA26151@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 03/01/2010 02:56 PM, Ingo Molnar wrote: > 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. > Kernel features and qemu features usually don't have a great amount of intersect. All of the problems you've described are strictly in the qemu space. > - It's released together with the kernel, which gives a periodic 3 months > release frequency. Not too slow, not too fast. > qemu release range in length from 3-6 months depending on distribution schedules. They are very regular. > - 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. > In our last release, we had around 100 contributors and about 100 KLOC of code written. We've got a lot of eyeballs and a lot of interest. > - 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. > Code quality is subjective. We have a different coding style. > - 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. > KVM has a backwards compatible ABI so there's no such thing as mismatch between user and kernel space. > - 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. > You could argue that any project should be in the kernel for these reasons. I see no reason why something as like KVM should be part of the kernel and udev shouldn't be. > 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. > You should try it. I think you'll find that it's not as obvious thing to do as you think it is. Regards, Anthony Liguori > Ingo >