From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bti91-0003Eg-NA for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:30:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bti8u-0001sD-OS for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:29:58 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:52807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bti8u-0001rq-Es for qemu-devel@nongnu.org; Mon, 10 Oct 2016 17:29:52 -0400 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9ALT4Ca001153 for ; Mon, 10 Oct 2016 17:29:51 -0400 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by mx0a-001b2d01.pphosted.com with ESMTP id 260e0rcemw-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Oct 2016 17:29:51 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Oct 2016 15:29:50 -0600 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:29:39 -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: <7a8f18cb-f393-fb06-605d-105fc55afb1e@linux.vnet.ibm.com> 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, mdroth@linux.vnet.ibm.com, mst@redhat.com, quintela@redhat.com, mark.cave-ayland@ilande.co.uk, qemu-devel@nongnu.org, mreitz@redhat.com, blauwirbel@gmail.com, amit.shah@redhat.com, qemu-ppc@nongnu.org, kraxel@redhat.com, dmitry@daynix.com, kwolf@redhat.com, rth@twiddle.net, leon.alrae@imgtec.com, aurelien@aurel32.net, david@gibson.dropbear.id.au 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 as you call it) structure. The idea was to use VMS_LINKED to indicate a recursive structure. In this patch is used on a queue. It can also be used on list or trees. In this regard, VMS_LINKED does represent something. 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 >