From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MdnxI-0001ZK-Rn
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:24:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MdnxE-0001YB-AM
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:24:08 -0400
Received: from [199.232.76.173] (port=44974 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MdnxE-0001Y2-46
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:24:04 -0400
Received: from [66.187.237.31] (port=50418 helo=mx2.redhat.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <quintela@redhat.com>) id 1MdnxD-0002nB-Eq
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 12:24:03 -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 n7JGNqin010500
	for <qemu-devel@nongnu.org>; Wed, 19 Aug 2009 12:23:52 -0400
From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <4A8C1869.1000200@redhat.com> (Gerd Hoffmann's message of "Wed,
	19 Aug 2009 17:21:13 +0200")
References: <cover.1250692287.git.quintela@redhat.com>
	<4A8C1869.1000200@redhat.com>
Date: Wed, 19 Aug 2009 18:21:35 +0200
Message-ID: <m363cjoju8.fsf@neno.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Qemu-devel] Re: [PATCH 0/3] New VMState table based
	load/save	infrastructure
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: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org

Gerd Hoffmann <kraxel@redhat.com> wrote:
>   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.

Agreed that the appreaches are very similar, basically question of style.

> 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;
> };

Trying to do pcibus_save() at the moment, and arrived at the conclusion
that we need the VMSTATE_INCLUDE() like thing.  Basically arrays need to
be handled the same:

struct dev_state {
    int32_t a[5];
}

struct dev_state {
    int32_t *a;
}

I am working on getting something like:

STRUCT(...)
STRUCT_P()
ARRAY()
ARRAY_P()

You get the idea :)

Later, Juan.