From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MlPO7-00020r-6U
	for qemu-devel@nongnu.org; Wed, 09 Sep 2009 11:47:15 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MlPO1-0001yC-Vx
	for qemu-devel@nongnu.org; Wed, 09 Sep 2009 11:47:14 -0400
Received: from [199.232.76.173] (port=40658 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MlPO1-0001y7-Nq
	for qemu-devel@nongnu.org; Wed, 09 Sep 2009 11:47:09 -0400
Received: from mail-qy0-f198.google.com ([209.85.221.198]:54244)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MlPO1-0008PW-75
	for qemu-devel@nongnu.org; Wed, 09 Sep 2009 11:47:09 -0400
Received: by qyk35 with SMTP id 35so3670238qyk.14
	for <qemu-devel@nongnu.org>; Wed, 09 Sep 2009 08:47:07 -0700 (PDT)
Message-ID: <4AA7CDEF.1060609@codemonkey.ws>
Date: Wed, 09 Sep 2009 10:46:55 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] The State of the SaveVM format
References: <m3hbvcijxc.fsf@neno.mitica> <4AA7BEA7.6080906@codemonkey.ws>
	<4AA7C823.8080909@redhat.com>
In-Reply-To: <4AA7C823.8080909@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>

Gerd Hoffmann wrote:
>> Which has to be an error. But this is the real problem with leaving the
>> old functions. It encourages sloppiness.
>
> I think we can kill most of the old load functions.  I'd keep the old 
> ones only in case emulating the old load function with vmstate would 
> make it unreasonable complex.

That would be more palatable.

>> static void marshal_pci_irq_levels(void *opaque, const char *name,
>> size_t offset, int load, int version)
>> {
>> if (version == 2) {
>> for (i = 0; i < 4; i++)
>> d->irq_state->piix3->pci_irq_levels[i] = qemu_get_be32(f);
>> }
>> }
>
>> VMSTATE_FUNC_V(irq_state->piix3->pci_irq_levels, PCII440FXState,
>> marshal_pci_irq_levels, 2)
>
> No.  I don't want any free-form C code in vmstate.  That will kill 
> quite a few of the vmstate advantages.  Imagine a tool dumping 
> snapshot data.  What this tool should do when it finds such a FUNC 
> field?  It has absolutely no idea what is in there ...

Well in this example, we could eliminate the function by just marking 
each of these fields as just being version 2.  One approach would be to 
have a version mask associated with each field.  That would provide an 
explicit bitmap of which versions were supported.  > N becomes (-1 << 
n), < N becomes ((1 << n) - 1), etc.  It also lets us support these 
weird cases where a field was present in v2, but not in v3 by just using 
an explicit mask.

We can use a uint64_t to start with and that will last us 32 years with 
a 6 month release cycle or 16 years with a 3 month release cycle.

Regards,

Anthony Liguori