From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlJa3-0006a6-El for qemu-devel@nongnu.org; Wed, 09 Sep 2009 05:35:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlJZy-0006Uy-88 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 05:35:10 -0400 Received: from [199.232.76.173] (port=36360 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlJZx-0006Ug-Tb for qemu-devel@nongnu.org; Wed, 09 Sep 2009 05:35:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16854) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlJZx-0001HN-DT for qemu-devel@nongnu.org; Wed, 09 Sep 2009 05:35:05 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n899Z4LX017182 for ; Wed, 9 Sep 2009 05:35:04 -0400 Date: Wed, 9 Sep 2009 12:33:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20090909093327.GC18061@redhat.com> References: <20090909085450.GA18061@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: The State of the SaveVM format List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org On Wed, Sep 09, 2009 at 11:22:50AM +0200, Juan Quintela wrote: > "Michael S. Tsirkin" wrote: > > On Wed, Sep 09, 2009 at 10:47:27AM +0200, Juan Quintela wrote: > >> More problems: Going from newer versions to old versions > >> - I think that everybody thinks that this is a nice to have, but that it > >> will took a lot to make it work, and there are more urgent things to > >> do. > > > > It's actually easy if you make whatever is new in the new version an > > optional feature. Then to save in an old format, qemu is started with > > the feature disabled. > > That only works if invariants are maintained. That is not true in > general. And furthermore, you are deciding that if you find a bug, and > fix needs a new field -> just live with the bug. Clarification: add an *option* to live with the bug, off by default. > If you can recreate the state without the new field, then _why_ did > you added it in the 1st place? > > Later, Juan.