On 10/05/2016 05:52 PM, Paolo Bonzini wrote: > > On 05/10/2016 16:29, Dr. David Alan Gilbert wrote: >> > The virtio-input conversion especially is nice and simple. >> > The only weird case is virtio-gpu, and well virtio-gpu is the one that's >> > odd here (compared to the rest of virtio). > Though virtio-gpu would be the one that could become nicer without the > macros. :) > > What I don't like about the macros is that they don't allow you to > extend the VMStateDescription. However, if you agree with Halil your > opinion counts more. > > Paolo >
Hi guys! Paolo you probably mean the fields part of the VMStateDescription. In my opinion it is an important question if we should want the ability to extend there. I was basing my assumptions on the series "[RFC 0/6] converting some of virtio to VMState" by Dave. This series designates VirtioDeviceClass.vmsd as the place for the state description of a specialized device which would normally belong to where Paolo wants it. The trouble in my opinion comes from the need to maintain compatibility which basically means put the data exactly the way it was. I do agree with Paolo that for new devices where this constrain is non-existent we could and probably should get rid of the virtio migration is very special stuff and do it normally. But for that in my opinion we first need to figure out what is the new way of virtio migration, document it, and provide an internal API for it. If we are going to do that, I think it will actually turn out beneficial, that if we name the weird (legacy) stuff differently because we can then name the new not-so-weird stuff according to the normal conventions. IMHO couple of questions to be answered before drafting the new approach are: * Is the proxy device (basically the transport) migrating itself or is it migrated by the transport agnostic device (e.g. virtio-net)? In my opinion these are two separate QOM/QDEV devices so they migrate separately. But this would arise some problems. * How is inheritance and VMState is supposed to work together, including versioning? In the meanwhile I have re-implemented the series following Paolo's suggestions (at least I hope) so I will send it out as a v2 shortly so we can make a direct comparison. Cheers, Halil
