qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] migration: Create block capabilities for sh


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 1/3] migration: Create block capabilities for shared and enable
Date: Mon, 15 May 2017 09:24:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 05/15/2017 04:46 AM, Dr. David Alan Gilbert wrote:
> * Juan Quintela (address@hidden) wrote:
>> Eric Blake <address@hidden> wrote:
>>> On 05/11/2017 11:32 AM, Juan Quintela wrote:
>>>> Those two capabilities were added through the command line.  Notice that
>>>> we just created them.  This is just the boilerplate.
>>>>
>>>> Signed-off-by: Juan Quintela <address@hidden>
>>>> Reviewed-by: Eric Blake <address@hidden>
>>>>
>>>> --
>>>>
>>>> Make migrate_set_block_* take a boolean argument.
>>>
>>> Question - do we support the orthogonal selection of all 4 combinations
>>> under HMP 'migrate' (no argument, -b alone, -i alone, -b and -i
>>> together), or are there only 3 actual states? If the latter, should we
>>> represent this as a single enum-valued property, rather than as two
>>> independent boolean properties?
>>
>> { 'enum': 'MigrationCapability',
>>   'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>>            'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram'] }
>>
>>
>> My understanding is that we can only have boolean capabilities here.
>> Or, how could we put a non-boolean capability?

If we want a non-boolean, then we make it a migration parameter rather
than a migration capability.  There may be other advantages to using
MigrationParameter instead of MigrationCapability (such as making it
easier to figure out whether the parameter settings are persistent or
apply per-migration).

> 
> Lets keep this simple and stick with the booleans.
> 
> Dave
> 
>> There are three states as far as I can see.

I'll leave it up to you as maintainers which way you prefer, I'm just
offering the potential design tradeoffs for simplicity of booleans (but
complexity in an unused state) vs. simplicity of design (but complexity
in code).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]