* Paolo Bonzini (pbonz...@redhat.com) wrote: > > > On 07/06/2016 18:34, Dr. David Alan Gilbert wrote: > > * Paolo Bonzini (pbonz...@redhat.com) wrote: > >> > >> > >> On 07/06/2016 16:43, Dr. David Alan Gilbert wrote: > >>> b) I think you should really try and split it into two parts: > >>> 1) A VMSTATE_ARRAY_CUSTOM (?) - so it's an array of elements but > >>> we've got a special > >>> way of allocating/counting/reading the elements > >>> 2) A version of that which is for a QTAILQ. > >>> It's important that whatever ends up on the migration stream > >>> doesn't reflect > >>> that it happens to be implemented as a QTAILQ; so if you decide to > >>> change > >>> it later the migration compatibility doesn't break. > >> > >> (Just to clarify before Jianjun wakes up) a VMSTATE_ARRAY is just a > >> sequence of elements. The count, if needed as in a VARRAY, is stored > >> earlier and separately. Currently lists (including this QTAILQ) are > >> usually represented in the migration stream as a sequence of elements > >> preceded by "1" and terminated by a "0". Would you like to change it to > >> a count + sequence as well? > >> > >> This would prevent using the new QTAILQ support for other existing lists > >> such as virtio-blk and scsi's request lists. > > > > That depends if it's something you're trying to keep migration compatibility > > with; if you're trying to keep format compaibility then sure keep it as is. > > If you're not trying to keep compatibility, then why can't virtio-blk or > > scsi request lists also use a count rather than the markers? > > We're trying to keep compatibility, and I think it's among the last bits > that are resisting conversion to vmstate. Which explains my interest in > Jianjun's patches. :)
OK, fine - if you're trying to keep format compatibility then I agree. Although I'm not entirely sure that things like virtio-blk, scsi and everything else are consistent in their structure. Dave > > Paolo > > >>> c) Use new trace_ names for get_qtailq rather than misusing > >>> trace_vmstate_load_state* > >>> d) Add a trace_ for put_qtailq as well - that way when it goes horribly > >>> wrong we can > >>> turn the tracing on on both sides :-) > >>> e) Is there anyway to make QTAILQ_RAW_INSERT_TAIL any more readable? > >>> I don't think I understand why you can't use the standard QTAILQ > >>> macros. > >> > >> Because they assume a particular type. The "raw" version need to work on > >> void*. > > > > Ah OK. > > > > Dave > > > >> > >> Thanks, > >> > >> Paolo > >> > >>> f) You might need to fix up Amit's scripts/vmstate-static-checker.py > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK