>> #
>> # Since: 1.2
>> ##
>> { '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?
Liang
