From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5eOF-0002G0-3Q for qemu-devel@nongnu.org; Wed, 25 May 2016 15:22:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5eOD-0005rw-2b for qemu-devel@nongnu.org; Wed, 25 May 2016 15:22:45 -0400 Date: Wed, 25 May 2016 15:22:34 -0400 (EDT) From: Paolo Bonzini Message-ID: <275886818.17251052.1464204154028.JavaMail.zimbra@redhat.com> In-Reply-To: <5745EF5D.8050705@linux.vnet.ibm.com> References: <1464112509-21806-1-git-send-email-duanj@linux.vnet.ibm.com> <1464112509-21806-5-git-send-email-duanj@linux.vnet.ibm.com> <5745D4E7.2000003@linux.vnet.ibm.com> <1171824705.17235966.1464198715349.JavaMail.zimbra@redhat.com> <5745EF5D.8050705@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [QEMU RFC PATCH v2 4/6] Migration: migrate QTAILQ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jianjun Duan Cc: qemu-devel@nongnu.org, quintela@redhat.com, mdroth@linux.vnet.ibm.com, qemu-ppc@nongnu.org, amit shah , david@gibson.dropbear.id.au > 1 QTAILQ should only be accessed using the interfaces defined in > queue.h. Its structs should not be directly used. So I created > interfaces in queue.h to query about its layout. If the implementation > is changed, these interfaces should be changed accordingly. Code using > these interfaces should not break. You don't need to query the layout, as long as the knowledge remains hidden in QTAILQ_RAW_* macros. And because QTAILQ_*_OFFSET returns constant values, you can just put the knowledge of the offsets directly in QTAILQ_RAW_FOREACH and QTAILQ_RAW_INSERT_TAIL. > 2 Based on point 1, vmstate_load_state/vmstate_put_state in vmstate.c > doesn't exactly know the structs of QTAILAQ head and entry. So pointer > arithmetic is needed to put/get a QTAILQ. To do it, we need those 6 > parameters to be passed in. So it is not redundant if we only want to > only use the interfaces. No, you only need two. The other four are internal to qemu/queue.h. Just like QTAILQ users do not know about tqh_* and tqe_*, they need not know about their offsets, only the fields that contain them. > 3 At this moment, vmstate_load_state/vmstate_put_state couldn't handle a > queue, or a list, or another recursive structure. To make it > extensible, I think a metadata is needed. The idea is for any > structure which needs special handling, customized metadata/put/get > should provide enough flexibility to hack around. I think your solution is a bit overengineered. If the metadata can fit in the VMStateField, you can use VMStateField. Thanks, Paolo