[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)

[John Snow]

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.