From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/2] Make savevm versioning compatible with upstream QEMU Date: Thu, 30 Apr 2009 16:29:55 +0300 Message-ID: <49F9A7D3.9040402@redhat.com> References: <1241038430-7444-1-git-send-email-aliguori@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:38572 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754825AbZD3N36 (ORCPT ); Thu, 30 Apr 2009 09:29:58 -0400 In-Reply-To: <1241038430-7444-1-git-send-email-aliguori@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Right now, there is no way savevm versioning can be compatible with upstream > QEMU because KVM adds fields to existing savevm structures without incrementing > the versions. > > If you assume that KVM will eventually merge into upstream QEMU, this means that > eventually KVM is going to have to break backwards compatibility with itself > to resolve this issue in a non-graceful way. > > So let's do that now instead of doing it later when the situation is only worse. > > I'm happy to allocate particular version identifiers for KVM to avoid future > conflicts. I believe we should try to eliminate the existing differences so > that we can converge in the future on a common versioning scheme. > Applied both, thanks. I think we can avoid the need to synchronize too much by saving kvm-specific state for device "x" using id "x-kvm"; this allows the two to evolve independently. Of course it's much better to avoid divergence in the first place, but this isn't always possible. -- error compiling committee.c: too many arguments to function