From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1budwr-00042H-Ul for qemu-devel@nongnu.org; Thu, 13 Oct 2016 07:13:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1budwo-000579-NH for qemu-devel@nongnu.org; Thu, 13 Oct 2016 07:13:17 -0400 Date: Thu, 13 Oct 2016 12:12:55 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161013111254.GB2169@work-vm> 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> <8b8b373d-34e9-00f3-9657-0ac4b5ade586@linux.vnet.ibm.com> <20161012145936.GB13343@work-vm> <0cf06165-ff45-b985-c6d3-ccf02d9f6eff@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cf06165-ff45-b985-c6d3-ccf02d9f6eff@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [QEMU PATCH v5 3/6] migration: extend VMStateInfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic Cc: Paolo Bonzini , Jianjun Duan , qemu-devel@nongnu.org, veroniabahaa@gmail.com, peter.maydell@linaro.org, mst@redhat.com, quintela@redhat.com, mark.cave-ayland@ilande.co.uk, mdroth@linux.vnet.ibm.com, mreitz@redhat.com, blauwirbel@gmail.com, amit.shah@redhat.com, qemu-ppc@nongnu.org, kraxel@redhat.com, kwolf@redhat.com, dmitry@daynix.com, rth@twiddle.net, leon.alrae@imgtec.com, aurelien@aurel32.net, david@gibson.dropbear.id.au * Halil Pasic (pasic@linux.vnet.ibm.com) wrote: > > > On 10/12/2016 04:59 PM, Dr. David Alan Gilbert wrote: > >> Paolo I agree on a theoretical level. It's just I do not see why this > >> > particular change makes the API simpler. In my opinion this complicates > >> > things because now all VMStateInfo's can do funky stuff. Having additional > >> > state you can poke is rarely a simplification. Same goes for lots > >> > of arguments especially if some of them are barely ever used. These > >> > additional parameters contribute nothing for the large majority > >> > of the cases (except maybe some head scratching when reading > >> > the code). > > I think it might depend how many VMStateInfo's we have. > > My ideal rule would be there are no .get/.put implementations outside > > of migration/ and we can trust that they would never do anything silly (right?); > > Your statement about ideally no .get/.put implementations outside > of migration/ is consistent with my initial understanding of VMStateInfo: > It's there to take care of the marshaling between the on wire representation > and the in memory representation of a single and preferably primitive > vmstate field (not consisting of further fields). Complex stuff like > arrays, structs, indirection via pointers and possibly allocation is > preferably handled elsewhere. So VMStateInfo is the basic building stones, > and the only place which should write to/read from the stream (in > ideal vmstate). > > So in a perfect vmstate world complete type of VMStateInfo is not part of the > API (you do not care about how it's done outside vmstate/), but only the > (possibly pointers to) VMStateInfo's supported by the vmstate API. > > Of course this is not realistic, at least at the moment. > > On the other hand if VMStateInfo is meant for complete customization, > as Jianjun has put it, then it obviously has to be a full fledged member > of the API, and I think then your ideal rule makes no sense to me. > > I also do think we will always need something for handling special > cases because we need to maintain compatibility -- see virtio migration > for example. > > > so the extra parameters aren't going to be misused too badly. > > > > What would you consider bad misuse? I do not see this as a big concern > at the moment. I don't know; but the only justification for needing the VMS_LINKED flag was that only those functions that were marked with VMS_LINKED would be passed the new field. Dave > Cheers, > Halil > > > However, we're probably quite a way from pulling all of the weirder > > .get/.put implementations back in. > > > > Dave > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK