From: Juan Quintela <quintela@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 4/5] New VMstate save/load infrastructure
Date: Wed, 19 Aug 2009 11:38:13 +0200 [thread overview]
Message-ID: <m3prasqh2y.fsf@neno.mitica> (raw)
In-Reply-To: <4A8BAE97.8010500@redhat.com> (Gerd Hoffmann's message of "Wed, 19 Aug 2009 09:49:43 +0200")
Reply-to: quintela@redhat.com
Gerd Hoffmann <kraxel@redhat.com> wrote:
>> +enum VMStateType {
>> + VMSTATE_TYPE_UNSPEC = 0,
>> + VMSTATE_TYPE_INT8,
>> + VMSTATE_TYPE_INT16,
>> + VMSTATE_TYPE_INT32,
>> + VMSTATE_TYPE_INT64,
>> + VMSTATE_TYPE_UINT8,
>> + VMSTATE_TYPE_UINT16,
>> + VMSTATE_TYPE_UINT32,
>> + VMSTATE_TYPE_UINT64,
>> + VMSTATE_TYPE_TIMER,
>> +};
>> +
>> +typedef struct VMStateInfo VMStateInfo;
>> +
>> +struct VMStateInfo {
>> + const char *name;
>> + size_t size;
>> + enum VMStateType type;
>> + void (*get)(QEMUFile *f, VMStateInfo *info, void *pv);
>> + void (*put)(QEMUFile *f, VMStateInfo *info, const void *pv);
>> +};
>> +
>> +typedef struct {
>> + const char *name;
>> + size_t num;
>> + size_t offset;
>> + VMStateInfo *info;
>> + int version_id;
>> +} VMStateField;
>
> 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)
and here, we go. The reaso that I don't need VMStateType anymore is
that now load/save are done:
+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);
+ }
+ field++;
+ }
+}
No need to have a type if we have the propper info struct. As this
struct is going to grow (at least 2 new pointers for printing into
monitor/read value from monitor), I think it is a good idea to maintain
the sharing.
Later, Juan.
> I think I would stick "enum VMStateType" directly into VMStateField
> and kill one level of indirection.
>
>> +
>> +typedef struct {
>> + const char *name;
>> + int version_id;
>> + int minimum_version_id;
>> + VMStateField *fields;
>> +} VMStateDescription;
>
> Add compat_load() callback for version_id < minimum_version_id here?
I am not sure where/what to add.
I liked your approach of having the new version clean, and let the old
code to deal with the mess that used to be here. Will take a look at
implementing soemething like that.
Thanks for the review, Juan.
next prev parent reply other threads:[~2009-08-19 9:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 13:34 [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 1/5] loadvm already call vm_start() Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 2/5] Don't call vm_start() if there was an error loading Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 3/5] Don't ignore load_state() error return values Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 4/5] New VMstate save/load infrastructure Juan Quintela
2009-08-18 17:13 ` Blue Swirl
2009-08-18 17:56 ` [Qemu-devel] " Juan Quintela
2009-08-19 7:49 ` [Qemu-devel] " Gerd Hoffmann
2009-08-19 9:38 ` Juan Quintela [this message]
2009-08-19 12:43 ` [Qemu-devel] " Gerd Hoffmann
2009-08-18 13:34 ` [Qemu-devel] [PATCH 5/5] Port apic to new VMState design Juan Quintela
2009-08-18 14:24 ` Reimar Döffinger
[not found] ` <20090818142405.GA16563@1und1.de>
[not found] ` <m37hx1tc9l.fsf@neno.mitica>
2009-08-18 15:21 ` [Qemu-devel] " Reimar Döffinger
2009-08-18 15:38 ` Juan Quintela
2009-08-18 16:06 ` Reimar Döffinger
2009-08-18 16:37 ` Juan Quintela
2009-08-19 8:00 ` Gerd Hoffmann
2009-08-19 9:10 ` Reimar Döffinger
[not found] ` <20090819085334.GA31062@1und1.de>
[not found] ` <4A8BC0C7.4010806@redhat.com>
2009-08-19 9:16 ` Reimar Döffinger
2009-08-19 7:41 ` [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure Gerd Hoffmann
2009-08-19 10:15 ` [Qemu-devel] " Juan Quintela
2009-08-19 12:55 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3prasqh2y.fsf@neno.mitica \
--to=quintela@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).