From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MdkWK-0003Hv-CY
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 08:44:04 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MdkWF-0003HH-FK
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 08:44:03 -0400
Received: from [199.232.76.173] (port=59586 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MdkWF-0003HE-Bw
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 08:43:59 -0400
Received: from [66.187.237.31] (port=44455 helo=mx2.redhat.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MdkWE-0004r0-PQ
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 08:43:59 -0400
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7JChv9j003265
	for <qemu-devel@nongnu.org>; Wed, 19 Aug 2009 08:43:57 -0400
Message-ID: <4A8BF388.6080401@redhat.com>
Date: Wed, 19 Aug 2009 14:43:52 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <cover.1250601335.git.quintela@redhat.com>	<e93c4a7becda20d35ae11bd07fe743fa91258364.1250601335.git.quintela@redhat.com>	<4A8BAE97.8010500@redhat.com>
	<m3prasqh2y.fsf@neno.mitica>
In-Reply-To: <m3prasqh2y.fsf@neno.mitica>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 4/5] New VMstate save/load infrastructure
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: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org

   Hi,

>> Hmm, I'm not sure VMStateInfo is that useful here.  All the get/put
>> callbacks are simple two-liners, and it is unlikely that the number of
>> types ever grows.
>
> Thinking about this.  VMStateType is not needed at all (see that it is
> not used in the patch).  But Ilike the VMStateInfo struct approach.
> This is the easier way of dealing with structs.  For instance
> pci_device_save().  My idea was to just create a new VMStateInfo for it,
> and then everything that needs to call pci_device_save() just add a
> field like:
>
> VMSTATE_FILED(dev, ThisPCIDevice, verion_id, pci_vmstate_info, PCIDevice)

Hmm.  I had a completely different approach in mind:

In pci.c:

vmstatefield pci_state[] = {
    VMSTATE_FIELD(...),
    [ ... ]
    VMSTATE_FIELD_END_OF_LIST()
}

In a pci driver:

vmstatefield device_state[] = {
    VMSTATE_INCLUDE(&pci_state, ...),
    VMSTATE_FIELD(...),
    [ ... ]
    VMSTATE_FIELD_END_OF_LIST()
}

Advantage: you don't have to write new code for each struct you want to 
save away state information from.

> +static void vmstate_save(QEMUFile *f, VMStateDescription *vmsd, void *base)
> +{
> +    VMStateField *field = vmsd->fields;
> +    int i;
> +
> +    while(field->name) {
> +        for (i = 0; i<  field->num; i++) {
> +            field->info->put(f, field->info, base + field->offset +
> +                             field->info->size * i);
> +        }

The other way would be dropping info and have
"switch(field->type) { ... }" here.

You indeed don't need both info and type.

Properties need the additional type field for typechecking in 
qemu_prop_set_$type() which doesn't use the print()/parse() callbacks.

cheers,
   Gerd