From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axxpT-00022w-VA for qemu-devel@nongnu.org; Wed, 04 May 2016 10:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axxpI-000239-BZ for qemu-devel@nongnu.org; Wed, 04 May 2016 10:31:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axxpI-0001zD-6N for qemu-devel@nongnu.org; Wed, 04 May 2016 10:30:56 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C90561A0B for ; Wed, 4 May 2016 14:30:45 +0000 (UTC) From: Juan Quintela In-Reply-To: <5729FB57.60904@redhat.com> (Eric Blake's message of "Wed, 4 May 2016 07:38:31 -0600") References: <87oa8mf4sj.fsf@emacs.mitica> <5729FB57.60904@redhat.com> Reply-To: quintela@redhat.com Date: Wed, 04 May 2016 16:30:42 +0200 Message-ID: <87shxxevzh.fsf@emacs.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Migration ToDo list (a.k.a. Rant) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: QEMU Developer Eric Blake 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.