[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)
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.
Re: [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)
On 11/18/2014 09:44 AM, John Snow wrote:
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.
Fair enough.
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' }
Ouch. Sounds like a bug in the code generator. Obviously, someone will
have to patch that (and add a testsuite entry to make sure it doesn't
regress) before we can rely on it.
...
{
.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.
We supposedly document it as working, but as no one is using it
(including no testsuite entry), I'm not surprised that it doesn't work yet.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
