From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] Rename KVM_UPSTREAM to OBSOLETE_KVM_IMPL Date: Tue, 14 Sep 2010 12:42:56 +0200 Message-ID: <4C8F51B0.8020508@siemens.com> References: <1284400455-29591-1-git-send-email-avi@redhat.com> <4C8E72E8.1090706@web.de> <4C8E73F0.6030302@codemonkey.ws> <4C8E7577.3020708@web.de> <4C8F4066.3020505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:19689 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752678Ab0INKnP (ORCPT ); Tue, 14 Sep 2010 06:43:15 -0400 In-Reply-To: <4C8F4066.3020505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? > >> 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"). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux