From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Domain Save Image Format proposal (draft B) Date: Tue, 11 Feb 2014 17:15:28 +0000 Message-ID: <1392138928.26657.134.camel@kazak.uk.xensource.com> References: <52F90A71.40802@citrix.com> <52FA043B020000780011B10C@nat28.tlf.novell.com> <21242.21415.38574.210861@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Cc: "Xen-devel@lists.xen.org" , Ian Jackson , David Vrabel , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Tue, 2014-02-11 at 11:08 -0600, Shriram Rajagopalan wrote: > I am not that familiar with ARM, but from what I read, its bi-endian > past v3. Modern ARMs can still do big endian, and are sometimes used that way too. I expect that this would be expressed as a new guest arch/type (ARMBE) though. But there's nothing wrong per-se with having the endianness of an image be explicit in the file formats header, even if it is a bit redundant. Note that the initial header has to be in some fixed endianness, but it's a small handful of bytes which only occurs once, I don't think the byte swapping is an issue there. Ian.