[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 4/5] New VMstate save/load infrastructure

From: Gerd Hoffmann
Subject: [Qemu-devel] Re: [PATCH 4/5] New VMstate save/load infrastructure
Date: Wed, 19 Aug 2009 14:43:52 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2


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[] = {
   [ ... ]

In a pci driver:

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]