From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54729 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q2Kqy-0004ny-H7
	for qemu-devel@nongnu.org; Wed, 23 Mar 2011 05:59:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1Q2Kqw-0007XW-9k
	for qemu-devel@nongnu.org; Wed, 23 Mar 2011 05:59:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:26324)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1Q2Kqv-0007XK-Tk
	for qemu-devel@nongnu.org; Wed, 23 Mar 2011 05:59:46 -0400
From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <1300839376-22520-8-git-send-email-aliguori@us.ibm.com> (Anthony
	Liguori's message of "Tue, 22 Mar 2011 19:16:12 -0500")
References: <1300839376-22520-1-git-send-email-aliguori@us.ibm.com>
	<1300839376-22520-8-git-send-email-aliguori@us.ibm.com>
Date: Wed, 23 Mar 2011 10:58:04 +0100
Message-ID: <m3ei5ygnv7.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Qemu-devel] Re: [PATCH 07/11] eeprom93xx: Use the new hack macro
	to avoid duplicate field names
Reply-To: quintela@redhat.com
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org

Anthony Liguori <aliguori@us.ibm.com> wrote:
> I don't fully understand this hack business but we need field to be unique so..
>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> ---
>  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)
>  {

After the fact, we need to promote it as "full types".

Basically it is needed when we sent a field with a different size that
we use it on the struct.

if we have

struct FOOState {
       int32_t bar;
....
}

and it is sent as

VMSTATE_INT8(bar, ....)

In this case, I went through the whole device, checed that int8_t was
enough and did the change.

But if we have:

struct FOOState {
       int8_t bar;
....
}

and it is sent as

VMSTATE_INT32(bar, ....)

Then it is not trivial :-(

We change FOOState to int32 or we break migration format.  Here is where
the _HACK suffix appeared.

I thought it was not going to be needed a lot, but there are several
devices that just sent everything over the wire as uint32, independently
of its type.

Later, Juan.