|
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:1.9.2.14) 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, uint16_t) + VMSTATE_SINGLE_TEST_HACK(_f, _s, _t, 0, vmstate_hack_uint16_from_uint8, uint16_t) static bool is_old_eeprom_version(void *opaque, int version_id) {Could we get away with just doing: VMSTATE_UNUSED(3), 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. Regards, ANthony Liguori
Later, Juan.
[Prev in Thread] | Current Thread | [Next in Thread] |