[Top][All Lists]

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

Re: [Qemu-devel] The State of the SaveVM format

From: Anthony Liguori
Subject: Re: [Qemu-devel] The State of the SaveVM format
Date: Wed, 09 Sep 2009 10:47:10 -0500
User-agent: Thunderbird (X11/20090825)

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.


Anthony Liguori

reply via email to

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