From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqltS-0000xM-56 for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:44:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqltL-0007q0-IM for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:44:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqltL-0007pc-9l for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:44:35 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAIGiYDR009445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 18 Nov 2014 11:44:34 -0500 Message-ID: <546B7771.2070608@redhat.com> Date: Tue, 18 Nov 2014 11:44:33 -0500 From: John Snow MIME-Version: 1.0 References: <1414639364-4499-1-git-send-email-famz@redhat.com> <1414639364-4499-3-git-send-email-famz@redhat.com> <545CC25E.5090405@redhat.com> In-Reply-To: <545CC25E.5090405@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] qmp-commands.hx and inherited types (Was: Re: [PATCH v6 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Max Reitz , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , Markus Armbruster On 11/07/2014 08:00 AM, Eric Blake wrote: > On 10/30/2014 04:22 AM, Fam Zheng wrote: [snip] >> +++ b/qapi/block-core.json >> @@ -865,6 +865,61 @@ >> '*on-target-error': 'BlockdevOnError' } } >> >> ## >> +# @BlockDirtyBitmap >> +# >> +# @device: name of device which the bitmap is tracking >> +# >> +# @name: name of the dirty bitmap >> +# >> +# Since 2.3 >> +## >> +{ 'type': 'BlockDirtyBitmap', >> + 'data': { 'device': 'str', 'name': 'str' } } >> + >> +## >> +# @BlockDirtyBitmapAdd >> +# >> +# @device: name of device which the bitmap is tracking >> +# >> +# @name: name of the dirty bitmap >> +# >> +# @granularity: #optional the bitmap granularity, default is 64k for >> +# block-dirty-bitmap-add > > Do you still need to call out the command, given that it is the only > client of this type? > >> +# >> +# Since 2.3 >> +## >> +{ 'type': 'BlockDirtyBitmapAdd', >> + 'data': { 'device': 'str', 'name': 'str', '*granularity': 'int' } } > > Is it worth using type inheritance, as in: > > { 'type': 'BlockDirtyBitmapAdd', > 'base': 'BlockDirtyBitmap', > 'data': { '*granularity': 'int' } } > Strictly speaking, I would argue against inheritance here because "BlockDirtyBitmapAdd" is not "isa" "BlockDirtyBitmap". It's more of a "Hasa" relationship. At any rate, I tried to implement this for giggles to see if I could, and ran into the following issue with which I'd be curious to get an answer for. As an example, If you have some type: { 'type': 'example', 'data': { 'foo': 'int' } } And an extension of it: { 'type': 'academicExample' 'base': 'example', 'data': { 'bar': 'str' } } How would you write a command that expected both "foo" and "bar"? The following doesn't seem appropriate (the generated code SKIPS the base fields, which leads to missing arguments in the prototype: { 'command': 'academic-command', 'data': 'academicExample' } ... { .name = "academic-command", .args_type = "foo:i,bar:s", .mhandler.cmd_new = qmp_marshal_input_academic_command, }, The generated prototype appears to skip the "foo" argument, including only the arguments associated with the base type, in this case, 'bar'. Do we support this kind of use? I didn't see it in-use currently, but I only gave it a cursory skimming.