From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buiw3-00026A-E9 for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:32:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buivz-0003IB-BE for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:32:47 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:42957 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buivz-0003I0-6O for qemu-devel@nongnu.org; Thu, 13 Oct 2016 12:32:43 -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 u9DGSSWF035725 for ; Thu, 13 Oct 2016 12:32:42 -0400 Received: from e06smtp08.uk.ibm.com (e06smtp08.uk.ibm.com [195.75.94.104]) by mx0a-001b2d01.pphosted.com with ESMTP id 262d4f2yt2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Oct 2016 12:32:42 -0400 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Oct 2016 17:32:39 +0100 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: Halil Pasic Date: Thu, 13 Oct 2016 18:32:31 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: <94b5a75f-3f74-ed05-2a1f-f45031f5debc@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: Jianjun Duan , 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 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? Cheers, Halil