Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL

Avi Kivity
2010-09-14T10:50:18Z

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