From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mdmyl-0000aI-OT
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 11:21:35 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mdmyh-0000UD-7Y
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 11:21:35 -0400
Received: from [199.232.76.173] (port=59485 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mdmyh-0000U0-3x
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 11:21:31 -0400
Received: from [66.187.237.31] (port=47064 helo=mx2.redhat.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Mdmyg-0004UP-IS
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 11:21:30 -0400
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7JFLIxM027294
	for <qemu-devel@nongnu.org>; Wed, 19 Aug 2009 11:21:18 -0400
Message-ID: <4A8C1869.1000200@redhat.com>
Date: Wed, 19 Aug 2009 17:21:13 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/3] New VMState table based
	load/save	infrastructure
References: <cover.1250692287.git.quintela@redhat.com>
In-Reply-To: <cover.1250692287.git.quintela@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.gnu.org/pipermail/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: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org

   Hi,

> - For structures, Kraxel suggested to use a VMSTATE_INCLUDE() instead of
>    having to declare a new VMStateInfo struct.  As I already have the new
>    struct code working, I sent it with the struct.  Thinking about how to
>    implement the VMSTATE_INCLUDE() and which one is easier to use.

Looked at your code and figured the two approaches are not that 
different.  I'd just put the pointer to the chained/included 
VMStateDescription directly into the VMStateField to avoid the (IMHO 
pointless) indirection via VMStateInfo.

Also:  It would probably useful to have two include modes here:  One for 
embedded structs, i.e. this:

struct dev_state {
   PCIDevice dev;
};

... and one for referenced structs, i.e. this:

struct dev2_state {
   PCIDevice *dev;
};

cheers,
   Gerd