[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 07/11] eeprom93xx: Use the new hack macro to avo

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 07/11] eeprom93xx: Use the new hack macro to avoid duplicate field names
Date: Wed, 23 Mar 2011 09:33:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/23/2011 09:14 AM, Juan Quintela wrote:
Anthony Liguori<address@hidden>  wrote:
On 03/23/2011 04:58 AM, Juan Quintela wrote:
Anthony Liguori<address@hidden>   wrote:
I don't fully understand this hack business but we need field to be unique so..

Signed-off-by: Anthony Liguori<address@hidden>
   hw/eeprom93xx.c |    2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/eeprom93xx.c b/hw/eeprom93xx.c
index cfa695d..f1d75ec 100644
--- a/hw/eeprom93xx.c
+++ b/hw/eeprom93xx.c
@@ -114,7 +114,7 @@ static const VMStateInfo vmstate_hack_uint16_from_uint8 = {

   #define VMSTATE_UINT16_HACK_TEST(_f, _s, _t)                           \
-    VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_hack_uint16_from_uint8, 
+    VMSTATE_SINGLE_TEST_HACK(_f, _s, _t, 0, vmstate_hack_uint16_from_uint8, 

   static bool is_old_eeprom_version(void *opaque, int version_id)
Could we get away with just doing:

VMSTATE_UINT8(bar, ...),
Remember that we are "supposed to be" big/little endian safe.

We always send in network byte order (big endian) so this is safe.

That's fully compatible on the wire and seems to be a clearer
expression of exactly what the problem is.
if we are going to break big endian machines, I fully agree.

The migration protocol is always big endian, see:

void qemu_put_be32(QEMUFile *f, unsigned int v)
    qemu_put_byte(f, v >> 24);
    qemu_put_byte(f, v >> 16);
    qemu_put_byte(f, v >> 8);
    qemu_put_byte(f, v);

So this is completely safe.


ANthony Liguori

Later, Juan.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]