Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 On 09/14/2010 12:42 PM, Jan Kiszka wrote:
Am 14.09.2010 11:29, Avi Kivity wrote:
>   On 09/13/2010 09:03 PM, Jan Kiszka wrote:
>>  Am 13.09.2010 20:56, Anthony Liguori wrote:
>>>  On 09/13/2010 01:52 PM, Jan Kiszka wrote:
>>>>  Am 13.09.2010 19:54, Avi Kivity wrote:
>>>>
>>>>>  The symbol KVM_UPSTREAM is used to mark sections of code that are
>>>>>  part of
>>>>>  the upstream kvm implemetation that is not used in qemu-kvm.  However
>>>>>  the
>>>>>  name becomes ambiguous if qemu-kvm is merged upstream.
>>>>>
>>>>  I doubt this is describing all cases correctly as well. Some changes
>>>>  should rather happen the other way around (e.g. you surely don't
>>>>  want to
>>>>  obsolete x86 kvm_arch_put/get_registers in favor of
>>>>  kvm_arch_load/save_regs, do you?).
>>>>
>>>  There's really no perfect name to describe what we're actually doing
>>>  here.  It's probably not a detail worth worrying that much about.
>>  I don't mind the name as long as it doesn't reflect the strategy (but
>>  why this change at all then?).
>
>  It would be silly to have a define KVM_UPSTREAM in upstream.

So the new plan is to dump qemu-kvm into upstream practically unmodified?

Yes. While the upstream implementation is cleaner, it lacks features and testing. So we'll work at cleaning the qemu-kvm implementation instead of improving the upstream one.

>
>>  Jan (who would prefer to have the time for doing the cleanups)
>>
>
>  Hopefully, with a single source base doing the cleanups would be easier,
>  so a more efficient use of the time we have.
>

I wouldn't expect much technical impact of this step. The effort of
comparing both code bases, merging the best of them together, and
testing the result will remain the same. Exposing the code via upstream
may attract new contributions, but then I'm a bit worried that people
could start work on removing the wrong part (as it is marked "obsolete").

It still lives forever in git. In any case, taking two code bases and merging them is much harder than picking one, however ugly, and beautifying it one bit at a time (also much easier to review).


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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux