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