>>> ##
>>> { 'enum': 'MigrationCapability',
>>> - 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
>>> }
>>> + 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>>>+ 'compress'] }
>>>
>>
>>I'll repeat what I said on v1 (but this time, with some links to back
>>it up :)
>>
>>We really need to avoid a proliferation of new commands, two per tunable does
>>not scale well. I think now is the time to implement my earlier suggestion
>>at making MigrationCapability become THE resource for tunables:
>>
>>https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html
>
>Hi Eric,
>
> I tried to follow your suggestion to implement a back-compat method to
> reuse the 'migrate-set-capabilities' and 'query-migrate-capabilities' , I
> found that I should change a lot of current code to make it work, and I don’t
> know how to deal with the HMP interface. So I add 'migrate-set-parameter'
> and 'query-migrate-parameter' interface to reduce the migrate-tunable
> commands, they can deal with all the 'int' type parameter, now the '
> compress-threads' ' , 'decompress-threads', and 'compress-level' and be
> set/queried with the two interfaces.
>
>{ 'enum': 'MigrationParameter',
> 'data': ['compress-level', 'compress-threads', 'decompress-threads'] }
>
>{ 'type': 'MigrationParameterStatus',
> 'data': { 'parameter' : 'MigrationParameter', 'value' : 'int' } }
>
> I am not sure if it's a good solution, but it's much more simple, and it
> can minimize the change of current code. Is that OK?
Hi Eric,
What do you think about this solution?
Liang
