>>> ## >>> { '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