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

[Anthony Liguori]

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