lkml.org 
[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project
On 03/22/2010 07:39 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>> On 03/22/2010 07:27 PM, Pekka Enberg wrote:
>>
>>> It's kinda funny to see people argue that having an external repository is
>>> not a problem and that it's not a big deal if building something from the
>>> repository is slightly painful as long as it doesn't require a PhD when we
>>> have _real world_ experience that it _does_ limit developer base in some
>>> cases. Whether or not that applies to kvm remains to be seen but I've yet
>>> to see a convincing argument why it doesn't.
>>>
>> qemu has non-Linux developers. Not all of their contributions are relevant
>> to kvm but some are. If we pull qemu into tools/kvm, we lose them.
>>
> Qemu had very few developers before KVM made use of it - i know it because i
> followed the project prior KVM.
>

No argument.

> So whatever development activitity Qemu has today, it's 99% [WAG] attributable
> to KVM. It might have non-Linux contributors, but they wouldnt be there if it
> wasnt for all the Linux contributors ...
>
> Furthermore, those contributors wouldnt have to leave - they could simply use
> a different Git URI ...
>

tools/kvm would drop support for non-Linux hosts, for tcg, and for
architectures which kvm doesn't support ("clean and minimal"). That
would be the real win, not sharing the repository. But those other
contributors would just stay with the original qemu.

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



\
 
 \ /
  Last update: 2010-03-22 19:01    [W:1.962 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site