On 06/10/2016 13:56, Dr. David Alan Gilbert wrote: >> > Yes, it's sickening but that's what you do to honor backwards >> > compatibility. > Actually, that's not *that* bad an idea. > > Lets go with Jianjun's structure for the moment; we can always expand on it. > > It seems we have ~3 concepts that feel partially independent: > > 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 specific > linked-list) > c) The data gathered in each iteration > d) The allocation of (c) > > 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, using > 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 one. I think this is acceptable, and it would only affect migration of USB storage devices. Paolo
