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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list