Eric Blake <ebl...@redhat.com> wrote: > On 05/04/2016 05:20 AM, Juan Quintela wrote: >> - migration capabilities and parameters >> this is a mess. Not, is worse than that. I don't know who is to >> blame here, but something needs to be done: >> >> void qmp_migrate_set_parameters(bool has_compress_level, >> int64_t compress_level, >> bool has_compress_threads, >> int64_t compress_threads, >> bool has_decompress_threads, >> int64_t decompress_threads, >> bool has_x_cpu_throttle_initial, >> int64_t x_cpu_throttle_initial, >> bool has_x_cpu_throttle_increment, >> int64_t x_cpu_throttle_increment, >> bool has_multifd_threads, >> int64_t multifd_threads, >> Error **errp) > > I've got a QAPI patch in the pipeline that makes this MUCH simpler, by > boxing everything through a single MigrationParameter* pointer rather > than an exploded list of parameters.
NICE!!! >> migrate_set_capability >> Minor nickpit, if it only allow booleans, >> "migrate_set_capability x-multifd", >> should be an equivalent of "migrate_set_capability x-multifd on" > > That's HMP - you can make HMP do whatever you want without breaking > back-compat. I would like to structure it as: Use the other way, this is deprecated and only here for backwards compatibility. >> migrate_set_cache_size >> migrate_set_downtime >> migrate_set_speed >> This three should be claimed obsolete, deprecated, whatever, and >> make it on top of next one > > Again, HMP can make this change easy, even if it has to call out to > different QMP under the hood. Yeap, but I preffer to have both consistent. >> >> Now to read the migration information: >> >> migrate_capabilities >> good >> migrate_parameters >> good > > Why we need two commands is beyond me - one command that lists > everything (capabilities AND parameters) should be sufficient. I don't care how we do it, but we need an easy way to be sure that when we add a new parameter/capability we also list it. Just now there are things that we can't get back. Later, Juan.
