On Wed, Mar 23, 2016 at 15:34:07 +0300, Nikolay Shirokovskiy wrote:
+typedef struct _qemuMonitorMigrationParameters qemuMonitorMigrationParameters; +typedef qemuMonitorMigrationParameters *qemuMonitorMigrationParametersPtr; +struct _qemuMonitorMigrationParameters { + unsigned int level_set : 1; + unsigned int threads_set : 1; + unsigned int dthreads_set : 1; + + int level; + int threads; + int dthreads; +};
Actually, I think the names should correspond to the names used by QEMU to avoid some confusion.
Ouch, this reveals some more misdesigned stuff. Look, I put qemuMonitorMigrationParameters into qemuMigrationCompression which is a kind of reverse aggregation. I see two options to make things the proper way here.
1. Rename qemuMonitorMigrationParameters, qemuMonitorSetMigrationParameters etc to add compression to the naming somehow. If actual qemu command will one day be extended to support parameters from different category - well we just add another json monitor command that will get/set the new subset of parametes.
2. Rework code so that we will aggregate all migration parameters into qemuMonitorSetMigrationParameters value and call actual qemu command only once. This way either we pack all compression values into one structure and have code that fills migration parameters value appropriately or we stop keeping compression related parameters in qemuMigrationCompression. I don't like any of these.
So i prefer the first option.
Originally, I inclined to some form of option 2, but now I agree option 1 would be better. At least until we have other migration parameters, but we can rethink the design if needed then. Jirka