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 -- 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
