From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs7hq-0005Ta-Gk for qemu-devel@nongnu.org; Thu, 06 Oct 2016 08:23:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bs7hn-0004eK-5E for qemu-devel@nongnu.org; Thu, 06 Oct 2016 08:23:22 -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> <959b58e3-82c3-af76-08e2-ca0fc61f7457@redhat.com> <20161006115609.GB3087@work-vm> From: Paolo Bonzini Message-ID: <561d3bf0-6df6-fabb-3c58-446bc0761b26@redhat.com> Date: Thu, 6 Oct 2016 14:23:09 +0200 MIME-Version: 1.0 In-Reply-To: <20161006115609.GB3087@work-vm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [QEMU PATCH v5 4/6] migration: migrate QTAILQ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Jianjun Duan , 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, kwolf@redhat.com, dmitry@daynix.com, rth@twiddle.net, leon.alrae@imgtec.com, aurelien@aurel32.net, david@gibson.dropbear.id.au On 06/10/2016 13:56, Dr. David Alan Gilbert wrote: >> > Yes, it's sickening but that's what you do to honor backwards compat= ibility. > Actually, that's not *that* bad an idea. >=20 > Lets go with Jianjun's structure for the moment; we can always expand o= n it. >=20 > It seems we have ~3 concepts that feel partially independent: >=20 > a) The format of the loop on the wire (eg one byte per iteration, 0= terminates) > b) The way the list is represented (QTAILQ, simple array, device sp= ecific linked-list) > c) The data gathered in each iteration > d) The allocation of (c) >=20 > This patch has a,b,d all wrapped up together in the get/put functions - > where I was hoping to find a way to separate them a bit so that we > could say; I want a loop, with this format, into this data structure, u= sing this allocator. Yes, the sickening part is when the format of the loop intersects with the format of the datastructure. I agree with moving the allocator out of VMStateInfo and back into VMStateField, but only as long as VMStateAllocator could replace other VMS_* flags. I'm not sure about the value in separating (a) and (b), but we can do things one step at a time. By the way, regarding this: > The other possibility is just to bump the version and make the SCSI > request flag a separate byte after the "is there another entry" byte. There is another way to do it that is much more backwards-compatible. Choose a "default" value of retry corresponding to what QEMU encodes as a "1". If it's different, use a subsection to encode that. Migration from old to new will fail if the wrong value of retry is used, because it will see a 2 where the QTAILQ loop expects a zero or one. Migration from new to old will fail if the wrong value of retry is used, because it will see a subsection header where the QTAILQ loop expects a zero or o= ne. I think this is acceptable, and it would only affect migration of USB storage devices. Paolo