> 1 QTAILQ should only be accessed using the interfaces defined in > queue.h. Its structs should not be directly used. So I created > interfaces in queue.h to query about its layout. If the implementation > is changed, these interfaces should be changed accordingly. Code using > these interfaces should not break.
You don't need to query the layout, as long as the knowledge remains hidden in QTAILQ_RAW_* macros. And because QTAILQ_*_OFFSET returns constant values, you can just put the knowledge of the offsets directly in QTAILQ_RAW_FOREACH and QTAILQ_RAW_INSERT_TAIL. > 2 Based on point 1, vmstate_load_state/vmstate_put_state in vmstate.c > doesn't exactly know the structs of QTAILAQ head and entry. So pointer > arithmetic is needed to put/get a QTAILQ. To do it, we need those 6 > parameters to be passed in. So it is not redundant if we only want to > only use the interfaces. No, you only need two. The other four are internal to qemu/queue.h. Just like QTAILQ users do not know about tqh_* and tqe_*, they need not know about their offsets, only the fields that contain them. > 3 At this moment, vmstate_load_state/vmstate_put_state couldn't handle a > queue, or a list, or another recursive structure. To make it > extensible, I think a metadata is needed. The idea is for any > structure which needs special handling, customized metadata/put/get > should provide enough flexibility to hack around. I think your solution is a bit overengineered. If the metadata can fit in the VMStateField, you can use VMStateField. Thanks, Paolo