On Mon, 30 Jul 2012 15:04:57 -0500 Anthony Liguori <aligu...@us.ibm.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> writes: > > > On Mon, 30 Jul 2012 14:45:04 -0500 > > Anthony Liguori <aligu...@us.ibm.com> wrote: > > > >> Orit Wasserman <owass...@redhat.com> 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 <owass...@redhat.com> > >> > Signed-off-by: Juan Quintela <quint...@redhat.com> > >> > >> 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.
