From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buinE-0002ij-7o for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:23:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buin9-0007AK-PP for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:23:40 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36895 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buin9-00079L-K5 for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:23:35 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9DGIjMY107008 for ; Thu, 13 Oct 2016 12:23:33 -0400 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 2629vqyxvx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Oct 2016 12:23:32 -0400 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Oct 2016 10:23:32 -0600 References: <1475519097-27611-1-git-send-email-duanj@linux.vnet.ibm.com> <1475519097-27611-4-git-send-email-duanj@linux.vnet.ibm.com> <60b19618-e725-710f-f512-3f6df471f6f2@linux.vnet.ibm.com> <1b5c6891-1cd2-bf92-0b8b-a0cd9312442f@linux.vnet.ibm.com> <1467348300.2794077.1476346928598.JavaMail.zimbra@redhat.com> <3e8b8f66-883e-6ea2-c191-6feaf4268110@linux.vnet.ibm.com> From: Jianjun Duan Date: Thu, 13 Oct 2016 09:23:20 -0700 MIME-Version: 1.0 In-Reply-To: <3e8b8f66-883e-6ea2-c191-6feaf4268110@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-Id: Subject: Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStateInfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic , Paolo Bonzini Cc: qemu-devel@nongnu.org, veroniabahaa@gmail.com, peter maydell , dgilbert@redhat.com, mst@redhat.com, quintela@redhat.com, mark cave-ayland , mdroth@linux.vnet.ibm.com, mreitz@redhat.com, blauwirbel@gmail.com, amit shah , qemu-ppc@nongnu.org, kraxel@redhat.com, kwolf@redhat.com, dmitry@daynix.com, rth@twiddle.net, leon alrae , aurelien@aurel32.net, david@gibson.dropbear.id.au On 10/13/2016 03:48 AM, Halil Pasic wrote: > > > On 10/13/2016 10:22 AM, Paolo Bonzini wrote: >>>> No, I disagree. We shouldn't be worried about making intrusive changes >>>>>> to all invocations or declarations, if that leads to a simpler API. >>>> >>>> If VMStateInfo was meant for complete customization, then it was missing >>>> some parts. I think the API is indeed simpler. Just like >>>> definition for VMStateField. Not all of its fields are used all time. >> Code moves. We can decide how much customization to allow of VMStateInfo. >> >> You said it: "Not all of its fields are used all time". Likewise, not >> all arguments are used all time for get/put, but it's not an issue if they >> are still there! So this patch is good, but at the same time VMS_LINKED is >> pointless. >> >> Paolo >> > > I'm fine with this. I just think, it would be nice if the contract between > the vmstate-core and the client code implementing VMStateInfo callbacks > could be documented, including when are certain parameters valid, what > they stand for, and how are they supposed to be used for the next version of > the patch. Just to improve readability. Would this be OK with everybody? > > By the way the flag VMS_SINGLE is documented as ignored. Should we drop > it? > I will prepare the VMStateInfo and QTAIL stuff as a separated series. If indeed VMS_SINGLE is ignored, I can drop it here. It is similar to VMS_LINKED situation. Thanks, Jianjun >