From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvwSd-0002vo-JN for qemu-devel@nongnu.org; Mon, 30 Jul 2012 16:21:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvwSb-0003us-U2 for qemu-devel@nongnu.org; Mon, 30 Jul 2012 16:21:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvwSb-0003uQ-Kk for qemu-devel@nongnu.org; Mon, 30 Jul 2012 16:21:01 -0400 Date: Mon, 30 Jul 2012 17:20:26 -0300 From: Luiz Capitulino Message-ID: <20120730172026.31af8b2a@doriath.home> In-Reply-To: <87haspnhg6.fsf@codemonkey.ws> References: <1343554983-4195-1-git-send-email-owasserm@redhat.com> <1343554983-4195-3-git-send-email-owasserm@redhat.com> <874nopc9tr.fsf@codemonkey.ws> <20120730165809.2788f1a1@doriath.home> <87haspnhg6.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/11] Add migrate_set_parameter and query-migrate-parameters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: peter.maydell@linaro.org, quintela@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, Orit Wasserman , chegu_vinod@hp.com, avi@redhat.com, pbonzini@redhat.com, eblake@redhat.com On Mon, 30 Jul 2012 15:04:57 -0500 Anthony Liguori wrote: > Luiz Capitulino writes: > > > On Mon, 30 Jul 2012 14:45:04 -0500 > > Anthony Liguori wrote: > > > >> Orit Wasserman writes: > >> > >> > The management can enable/disable a capability for the next migration by using > >> > migrate_set_parameter command. > >> > The management can query the current migration capabilities using > >> > query-migrate-parameters > >> > > >> > Signed-off-by: Orit Wasserman > >> > Signed-off-by: Juan Quintela > >> > >> We have a way to add new commands. Let's not invent a new one. > >> Otherwise every subsystem would have it's own approach to querying > >> what's available. > > > > I think it does make sense for setting/getting migration's capabilities, which > > are just booleans. And that's what the commands currently do, btw. > > > > I'd only recommend to rename them to migrate_set_capability > > query-migrate-capabilities. > > If that's the intent, it should take/return a list of capabilities > (expressed as an enum). Yes, it already does it iirc. Now, there's something I'm not sure about. This series adds three commands: - migrate-set-parameter (should be renamed to migrate-set-capabilities) - query-migrate-parameters (should be renamed to query-migrate-capabilities) - query-migration-capabilities (should be dropped?) That last command returns the supported capabilities. We should either, rename it to query-migration-supported-capabilities or just drop it, because if a capability appears in (this series') query-migrate-parameters it means that the capability is supported.