From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: Domain Save Image Format proposal (draft B) Date: Tue, 11 Feb 2014 10:58:56 +0000 Message-ID: <52FA0270.7040501@citrix.com> References: <52F90A71.40802@citrix.com> <52F97E6F.2000402@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: rshriram@cs.ubc.ca, Andrew Cooper Cc: David Vrabel , Ian Jackson , Ian Campbell , Stefano Stabellini , "Xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 11/02/14 04:12, Shriram Rajagopalan wrote: > On Mon, Feb 10, 2014 at 7:35 PM, Andrew Cooper >> The marker field can be used to distinguish between legacy >> images and >> those corresponding to this specification. Legacy images will >> have at >> one or more zero bits within the first 8 octets of the image. >> >> Fields within the image header are always in _big-endian_ byte >> order, >> regardless of the setting of the endianness bit. >> >> >> and more endian-ness mess. > > Network order is perfectly valid. Is is how all your network > packets arrive... > > > > > True. But why should we explicitly convert the application level data to > network byte order and then convert it back to host byte order, when its > already going to be done by the underlying stack, as you put it? TCP doesn't change the byte order of the payload, only header fields are defined to be in big endian, AFAIK. Zoli