From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7JBP-0003aI-BJ for qemu-devel@nongnu.org; Tue, 23 Jun 2015 04:03:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7JBK-0006RM-OZ for qemu-devel@nongnu.org; Tue, 23 Jun 2015 04:03:51 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:25322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7JBK-0006QM-6K for qemu-devel@nongnu.org; Tue, 23 Jun 2015 04:03:46 -0400 Message-ID: <558912C8.4040306@huawei.com> Date: Tue, 23 Jun 2015 16:03:20 +0800 From: zhanghailiang MIME-Version: 1.0 References: <20150605095004.GB2139@work-vm> <55815000.8060300@huawei.com> <87d20st8vt.fsf@blackfin.pond.sub.org> <5588B9C8.9060800@huawei.com> <877fquzwwi.fsf@blackfin.pond.sub.org> In-Reply-To: <877fquzwwi.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Adding new migration-parameters - any easier way? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, amit.shah@redhat.com, peter.huangpeng@huawei.com, "Dr. David Alan Gilbert" , quintela@redhat.com On 2015/6/23 15:50, Markus Armbruster wrote: > zhanghailiang writes: > >> On 2015/6/19 16:11, Markus Armbruster wrote: > [...] >>> To avoid the ugliness, we could change the QAPI generator. Currently, >>> >>> { 'command': 'migrate-set-parameters', >>> 'data': 'MigrationParameters' } >>> >>> generates the same interface as when you inline MigrationParameters, >>> namely >>> >>> void qmp_migrate_set_parameters(bool has_compress_level, >>> int64_t compress_level, >>> bool has_compress_threads, >>> int64_t compress_threads, >>> bool has_decompress_threads, >>> int64_t decompress_threads, >>> ... more ... >>> Error **errp) >>> >>> It could instead generate >>> >>> void qmp_migrate_set_parameters(MigrationParameters *parms, >>> Error **errp) >>> >>> No change to the wire protocol. Fairly big, but relatively mechanical >>> change to the handler functions. I'd be willing to give it a shot and >>> see how it turns out, but I can't do it for 2.4, sorry. >>> >> >> Great, that would be fine~ Thanks. > > I think I can give it a try myself some time in the 2.5 cycle. > OK, thanks~ :)