From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btiJ1-0007as-TY for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:40:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btiIx-0006zY-No for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:40:18 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btiIx-0006z0-EM for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:40:15 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9ALcfDU068311 for ; Mon, 10 Oct 2016 17:40:14 -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 260e3bvnx8-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Oct 2016 17:40:14 -0400 Received: from localhost by e19.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Oct 2016 17:40:13 -0400 References: <1475519097-27611-1-git-send-email-duanj@linux.vnet.ibm.com> <1475519097-27611-5-git-send-email-duanj@linux.vnet.ibm.com> <20161005165638.GC11921@work-vm> <20161006190156.GE3087@work-vm> <6420ae77-c205-6e24-d06e-2bbb28447b23@redhat.com> <20161007143445.GA25928@work-vm> <72a0ee2a-297c-02cd-1af5-215ad463b474@linux.vnet.ibm.com> <7e2948b3-0e29-b87c-78bd-d5070efb3342@redhat.com> <32187d3f-d1c1-b14a-ebf6-f01526359bdb@linux.vnet.ibm.com> <20161007173448.GD25928@work-vm> <769fa4cd-4960-396e-c2ae-c11508f69f0d@redhat.com> <02caeaca-5a35-4efa-39be-772d1a314d74@linux.vnet.ibm.com> From: Jianjun Duan Date: Mon, 10 Oct 2016 14:40:03 -0700 MIME-Version: 1.0 In-Reply-To: <02caeaca-5a35-4efa-39be-772d1a314d74@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Message-Id: Subject: Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 4/6] migration: migrate QTAILQ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic , Paolo Bonzini , "Dr. David Alan Gilbert" Cc: veroniabahaa@gmail.com, peter.maydell@linaro.org, quintela@redhat.com, mst@redhat.com, mark.cave-ayland@ilande.co.uk, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, dmitry@daynix.com, qemu-ppc@nongnu.org, kraxel@redhat.com, david@gibson.dropbear.id.au, amit.shah@redhat.com, kwolf@redhat.com, mreitz@redhat.com, leon.alrae@imgtec.com, aurelien@aurel32.net, rth@twiddle.net On 10/08/2016 12:28 PM, Halil Pasic wrote: > > > On 10/08/2016 01:37 PM, Paolo Bonzini wrote: >>> Even though most put/get have no issues now, when somebody writes a new >>>> put, he or she could run into issues if only checking the type >>>> signature. It makes the code more readable. > >> No, it doesn't because one is left wondering what is VMS_LINKED about. > > I agree with Paolo. IMHO VMS_LINKED is conceptually difficult in a sense > that it's quite different that what we have currently. I have the feeling, > conceptually, we are trying to fit in something like data structures with a > type parameter (the element type) here. AFAIU what vmstate currently can is > directed acyclic graphs of certain stuff (and also completely custom > handling based on custom put/get). > You are right. What we have in vmstate now cannot handle a recursive or cyclic structure in a generic way. VMS_LINKED is intended to indicate a recursive structure, with the newly added parameters of put/get providing information about the element type in the recursive structure. Thanks, Jianjun >> What is the relation between linked datastructures and passing some >> arguments as NULL/noon-NULL? > > IFAIU we need those for the datastructure because it's linked and has > a type parameter (element type). The two last arguments are for > the element type. These were added by the previous patch because > the old VMStateInfo did not need these. So we drastically changed > the scope of VMStateInfo with the previous patch and I'm not > sure I like this. > > I will have to stare at this a bit longer to bring something more > constructive than these (largely feeling-based) remarks. > > Cheers, > Halil >