Re: Domain Save Image Format proposal (draft B)

[Shriram Rajagopalan <rshriram@cs.ubc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 3091 bytes --]

On Tue, Feb 11, 2014 at 10:45 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>wrote:

> Jan Beulich writes ("Re: [Xen-devel] Domain Save Image Format proposal
> (draft B)"):
> > On 10.02.14 at 18:20, David Vrabel <david.vrabel@citrix.com> 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.
>
>
Yes and Yes. But why resort to Network Byte Order at all when we
don't have support any architectures using big endian?

Are we thinking of transferring images or migrating data between machines
that have
different endian-ness? Its not like network elements such as middleboxes
(which could probably be big-endian ) are going to interpret the
application
level data and take routing decisions.

I am not that familiar with ARM, but from what I read, its bi-endian past
v3.
Don't think we have plans to support SPARC, which too is bi-endian
beyond a certain version IIRC.

That leaves legacy ARMs and SPARC that use big endian mode.

So am I missing something elementary here Ian? Why the emphasis on
network byte order? I certainly agree that the byte order should be declared
once in the header, so that there would be no confusion on how to interpret
it.



> > > 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.
>
>

[-- Attachment #1.2: Type: text/html, Size: 4313 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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