On Tue, Jun 07, 2016 at 06:31:41PM +0200, Paolo Bonzini 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.
And if you migrate the count, you must validate that it's not bigger than an actual array size before VARRAY. > 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. > > > 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*. > > Thanks, > > Paolo > > > f) You might need to fix up Amit's scripts/vmstate-static-checker.py
