[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BA6B6F0.9080201@codemonkey.ws>
Date: Sun, 21 Mar 2010 19:16:48 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Ingo Molnar <mingo@...e.hu>
CC: Avi Kivity <avi@...hat.com>, Pekka Enberg <penberg@...helsinki.fi>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Sheng Yang <sheng@...ux.intel.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
oerg Roedel <joro@...tes.org>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Gleb Natapov <gleb@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
project
On 03/21/2010 04:54 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@...hat.com> wrote:
>
>
>> On 03/21/2010 10:55 PM, Ingo Molnar wrote:
>>
>>> Of course you could say the following:
>>>
>>> ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not
>>> able to add this to the v2.6.35 kernel queue anymore as the ongoing
>>> usability work already takes up all of the project's maintainer and
>>> testing bandwidth. If you want the feature to be merged sooner than that
>>> then please help us cut down on the TODO and BUGS list that can be found
>>> at XYZ. There's quite a few low hanging fruits there. '
>>>
>> That would be shooting at my own foot as well as the contributor's since I
>> badly want that RCU stuff, and while a GUI would be nice, that itch isn't on
>> my back.
>>
> I think this sums up the root cause of all the problems i see with KVM pretty
> well.
>
A good maintainer has to strike a balance between asking more of people
than what they initially volunteer and getting people to implement the
less fun things that are nonetheless required. The kernel can take this
to an extreme because at the end of the day, it's the only game in town
and there is an unending number of potential volunteers. Most other
projects are not quite as fortunate.
When someone submits a patch set to QEMU implementing a new network
backend for raw sockets, we can push back about how it fits into the
entire stack wrt security, usability, etc. Ultimately, we can arrive at
a different, more user friendly solution (networking helpers) and along
with some time investment on my part, we can create a much nicer, more
user friendly solution. Still command line based though.
Responding to such a patch set with, replace the SDL front end with a
GTK one that lets you graphically configure networking, is not
reasonable and the result would be one less QEMU contributor in the long
run.
Overtime, we can, and are, pushing people to focus more on usability.
But that doesn't get you a first class GTK GUI overnight. The only way
you're going to get that is by having a contributor be specifically
interesting in building such a thing.
We simply haven't had that in the past 5 years that I've been involved
in the project. If someone stepped up to build this, I'd certainly
support it in every way possible and there are probably some steps we
could take to even further encourage this.
Regards,
Anthony Liguori
--
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