Message-ID: <4B937363.4070406@redhat.com>
Date:	Sun, 07 Mar 2010 11:35:31 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Zachary Amsden <zamsden@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>, ming.m.lin@...el.com,
	sheng.yang@...el.com, Jes Sorensen <Jes.Sorensen@...hat.com>,
	KVM General <kvm@...r.kernel.org>,
	Gleb Natapov <gleb@...hat.com>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: KVM usability

On 03/02/2010 12:30 PM, Ingo Molnar wrote:
> * Ingo Molnar<mingo@...e.hu>  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.
>>      
> Just look at an example from today, a perf+KVM feature patch posted by Yanmin
> Zhang:
>
>    http://www.mail-archive.com/kvm@vger.kernel.org/msg29770.html
>
> That single patch implements the following "perf kvm" commands:
>
>    perf kvm top
>    perf kvm record
>    perf kvm report
>    perf kvm diff
>
> Both the kernel-space and the user-space changes are in that single patch.
>
> Anyone who'd like to try it out can apply it and get an updated kernel plus
> updated tooling and can start profiling KVM guests straight away. You just
> check out the kernel, apply the patch and that's it - you can go. It doesnt
> get any more convenient than that to do development.
>
> Such kind of a unified repository is a powerful concept, and we make use of
> those aspects of tools/perf/ every day. You could only pry it out of our cold,
> dead fingers ;-)
>    

perf really is wonderful, but to be really competitive, and usable to 
more developers, it needs to be in a graphical environment.  I want 
'perf report' output to start out collapsed and drill down by clicking 
on a tree widget.  Clicking on a function name opens its definition.  
'perf annotate' should display annotations on my editor window, not in a 
pager.  I should be able to check events on a list, not using 'perf list'.

Is something like that suitable for tools/perf/?  I think you'll find 
the intersection of kernel developers and GUI developers to be fairly small.

> Btw., this is one of the things that FreeBSD does right - and i believe it is
> one of the technical concepts behind Apple's success as well. Apple, with a
> tenth's of Linux's effective R&D budget can consistently out-develop Linux. I
> think that's in part due to there not being a strict chinese wall between the
> Apple kernel, libraries and applications - it's one coherent project where
> everyone is well-connected to each piece, with no artificial project-cultural
> boundaries and barriers. People can and do move between those areas of the
> larger "Apple" project to achieve their goals - regardless of how many
> components need touching for a given area of interest.
>
> IMHO we should learn from that - while we are good in many areas there's
> always aspects of Linux that can be improved. But i digress.
>    

Folding everything into the kernel tree is one way to approach it; IMO 
it is completely unreasonable.  The kernel is a very small part of a 
complete system.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists