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. > 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
