Hi.
I'm not sure if I follow, but I'll try to explain my reasoning as best I can.
What I meant by
>magic will stay the same on both BE and LE machines
was, that if we print the variable, we get the same result.
If we store the magic as a string converted to uint32 and we print the value we get a
different result on LE and BE machine, meaning that on both machines, the bytes are
stored in exactly the same order (QUIC).
When we send the magic from LE server, it sends as is (QUIC), but on client it
swaps the bytes (CIUQ). This is then compared to locally stored magic, which is
stored the same way as on the server (QUIC), and if we want them to be the same,
we have to do a second swap.
As you said, we don't want this. We want them to be stored in the native
endianness. When I use the second option (hex value), the machine stores
the value natively, because I supply a number, not a value to be stored in
memory, and a number is then stored in native endianness.
The number 0x43495551 will be stored as CIUQ on LE machine and QUIC on BE machine.
When when we send the magic from LE server, we send it as is (CIUQ), but when swapped
on the client, it becames QUIC, which is compared to local magic, which is also QUIC.
Therefore we actually don't need to double swap using this method.
I made this minimal example to test it on both LE and BE machine:
---
#include <stdio.h>
#define QUIC_MAGIC_OLD (*(unsigned int *)"QUIC")
#define QUIC_MAGIC_NEW 0x43495551
int main(void)
{
printf("QUIC_MAGIC_OLD: %d\nQUIC_MAGIC_NEW: %d\n", QUIC_MAGIC_OLD, QUIC_MAGIC_NEW);
return 0;
}
---
BE result:
QUIC_MAGIC_OLD: 1364543811
QUIC_MAGIC_NEW: 1128879441
LE result:
QUIC_MAGIC_OLD: 1128879441
QUIC_MAGIC_NEW: 1128879441
If I understand endianness correctly, if the numbers match, it means,
that the value is stored natively.
I will reword the commit log on both this commit and the one with QUIC magic to include this explanation.
I hope that answers your concerns.
Lukas
----- Original Message -----
> From: "Christophe Fergeau" <cfergeau@xxxxxxxxxx>
> To: "Lukas Venhoda" <lvenhoda@xxxxxxxxxx>
> Cc: spice-devel@xxxxxxxxxxxxxxxxxxxxx
> Sent: Friday, June 19, 2015 11:34:39 AM
> Subject: Re: [spice-common PATCH 1/3] ppc: Fix lz magic endianess
>
> On Thu, Jun 18, 2015 at 07:50:26PM +0200, Lukas Venhoda wrote:
> > Commit d39dfbfe changes to be lz magic always treated as LE when encoded.
> >
> > Changing lz magic to constant instead of a runtime coversion from string
> > to int is a better way to go. This way lz magic will stay the same on
> > both BE and LE machines.
>
> I'm not sure how to read it here, what happens is that encode_32() will
> do the byte swapping for us, so we can store the magic in the native
> endianness, and let encode_32() do the work instead of having the
> constant hard coded to little-endian, and having to double-swap it on
> big endian platforms (we byteswap it before passing it to encode_32(),
> which is going to byteswap it again, which gives a no-op).
>
> ACK, unless you want to improve the commit log.
>
> Christophe
>
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel