Re: [Xen-devel] [PATCH 1/3] docs: specify endianess of xenstore protocol header

[Juergen Gross <jgross@xxxxxxxx>]

On 08/05/17 12:07, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 1/3] docs: specify endianess of xenstore 
> protocol header"):
>> The endianess of the xenstore protocol header should be specified.
> ...
>> -followed by xsd_sockmsg.len bytes of payload.
>> +followed by xsd_sockmsg.len bytes of payload. The header fields are
>> +all in little endian byte order.
> 
> Yes, but this is not correct.  On a big-endian cpu, they would be in
> big-endian.

We don't support big-endian cpus, right? Do we want to specify the
protocol for unsupported cpus?

> On a bytesexual cpu, the endianness should be specified but it will be
> the same endianness as shared ring fields, etc.  So this doc probably
> ought not to contain a list of endiannesses.  Best just to say that
> the fields are all in host native byte order.

Hmm, this is problematic. How does a guest started e.g. big-endian on a
cpu capable of both byte orders know which endianess the host has? I
think specifying one endianess in this case is the better approach.

BTW: I'm quite sure we don't support big-endian guests (or host) on ARM
either, do we?

I could reword the paragraph to:

"The header fields are in the default endianess of the processor, e.g.
little endian on x86 and ARM."


Juergen


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