Re: [Xen-devel] Domain Save Image Format proposal (draft B)

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] Domain Save Image Format proposal (draft 
B)"):
> On 10.02.14 at 18:20, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> > Fields
> > ------
> > 
> > All the fields within the headers and records have a fixed width.
> > 
> > Fields are always aligned to their size.
> > 
> > Padding and reserved fields are set to zero on save and must be
> > ignored during restore.
> 
> Meaning it would be impossible to assign a meaning to these fields
> later. I'd rather mandate that the restore side has to check these
> fields are zero, and bail if they aren't.

I disagree.  It is precisely the fact that they are ignored which
makes it possible to assign meaning to them later.

It is easy enough to make old readers bail.  What is good about
David's spec is the room for enhancement _without_ making old readers
bail.

I would like to see is that the version number does not normally need
to be incremented.  For example, the .deb package format which I
designed in 1993 has stayed at version 2.0 even though it has been
heavily extended in a number of directions.

> > Integer (numeric) fields in the image header are always in big-endian
> > byte order.
> 
> Why would big endian be preferable when both currently
> supported architectures use little endian?

Because (a) that's Network Byte Order (b) there are convenient
functions for dealing with endian-conversion.

> > 1. Image header
> > 2. Domain header
> > 3. X86_PV_INFO record
> > 4. At least one P2M record
> > 5. At least one PAGE_DATA record
> > 6. VCPU_INFO record
> > 6. At least one VCPU_CONTEXT record
> > 7. END record
> 
> Is it necessary to require this strict ordering? Obviously the headers
> have to be first and the END record last, but at least some of the
> other records don't seem to need to be at exactly the place you list
> them.

It's necessary to define some constraints on the ordering.  In
practice the receiving implementation may or may not work with all
orderings and defining a particular ordering is probably easiest.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel