From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bubHz-0006Ox-Co for qemu-devel@nongnu.org; Thu, 13 Oct 2016 04:22:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bubHy-0004Jk-DC for qemu-devel@nongnu.org; Thu, 13 Oct 2016 04:22:55 -0400 Date: Thu, 13 Oct 2016 04:22:08 -0400 (EDT) From: Paolo Bonzini Message-ID: <1467348300.2794077.1476346928598.JavaMail.zimbra@redhat.com> In-Reply-To: <1b5c6891-1cd2-bf92-0b8b-a0cd9312442f@linux.vnet.ibm.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 Cc: Halil Pasic , 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 > > 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 agree that overloading .start can be a bit ugly but you can choose to > > overload .num_offset instead, which is already better. > > > I did considered num_offset. But it is associated with an actual field. > On the other hand, start means the start position of the q in the > structure. So it is not that far stretched. > > >> I would also suggest unit tests in test/test-vmstate.c. Maybe with > >> that the vmstate migration of QTAILQ could be factored out as a separate > >> patch series. > > > > Yes, definitely. > > > This sounds a good idea. Will do it. > > > Paolo > > > Thanks, > Jianjun > >