From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buizO-00059k-Oa for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:36:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buizL-0004p1-FU for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:36:14 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47704 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buizL-0004of-9K for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:36:11 -0400 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9DGSRHa035633 for ; Thu, 13 Oct 2016 12:36:10 -0400 Received: from e19.ny.us.ibm.com (e19.ny.us.ibm.com [129.33.205.209]) by mx0a-001b2d01.pphosted.com with ESMTP id 262d4f356k-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Oct 2016 12:36:10 -0400 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Oct 2016 12:36:10 -0400 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> <94b5a75f-3f74-ed05-2a1f-f45031f5debc@linux.vnet.ibm.com> From: Jianjun Duan Date: Thu, 13 Oct 2016 09:35:59 -0700 MIME-Version: 1.0 In-Reply-To: <94b5a75f-3f74-ed05-2a1f-f45031f5debc@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-Id: <3fb75753-d8b5-cf91-4106-39aeae9a1e3a@linux.vnet.ibm.com> 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 09:32 AM, Halil Pasic wrote: > > > On 10/13/2016 06:23 PM, Jianjun Duan wrote: >> >> >> 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 > > I think it's completely unrelated, so I would not lump it together with > the QTAILQ stuff. > > How do you feel about the apidoc part? > I will add some comments inside vmstate_save/load_state about it. Thanks, Jianjun > Cheers, > Halil >