Re: KVM usability

Avi Kivity
2010-03-07T09:37:39Z

On 03/02/2010 12:30 PM, Ingo Molnar wrote:
> * Ingo Molnar<mingo@elte.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