All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Federico Simoncelli <fsimonce@redhat.com>,
	Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2
Date: Mon, 21 May 2012 16:47:05 +0200	[thread overview]
Message-ID: <4FBA5569.2030405@redhat.com> (raw)
In-Reply-To: <4FBA53E9.2030800@codemonkey.ws>

Il 21/05/2012 16:40, Anthony Liguori ha scritto:
> On 05/21/2012 09:26 AM, Paolo Bonzini wrote:
>> Il 21/05/2012 16:19, Anthony Liguori ha scritto:
>>>>
>>>
>>> I'm not against it in principle, just in practice.  Today, checking
>>> whether a command exists is:
>>>
>>> commands = qmp.query_commands()
>>>
>>> if 'block-stream' in commands:
>>>      # has block-stream
>>>
>>> I have a hard time envisioning how schema introspection can be
>>> reasonably implemented in a client.
>>
>> schema = qmp.query_command_schema('block-stream')
> 
> What would schema return?
> 
> Did you mean:
> 
> if schema['arguments'].has_key('on_error'):

Yes, something like that.

> What about adding a parameter to a structure?

schema = qmp.query_type('foo')
if schema['data'].has_key('xyz')

> BTW, the other problem with adding arguments like this is that it makes
> a stable C API impossible.

Adding fields to structs is not a problem as long as "libqmp" takes care
of all allocations on part of its client.  Adding parameters to commands
requires some smartness, but there are ways to do it:

1) add the first version number to the schema, generate versioned entry
points

qmp_block_stream_v1_1
qmp_block_stream_v1_2

etc.  Provide multiple headers libqmp-1.1.h, libqmp-1.2.h etc. that take
care of #define'ing qmp_block_stream to one of them

2) Same as (1) but use qmp_block_stream for the oldest version having
the command.

3) have fun with the preprocessor (macro with variable arguments,
sizeof, designated initializers, whatever) and emulate keyword arguments
for the C API.

Paolo

  reply	other threads:[~2012-05-21 14:47 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 17:08 [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2 Paolo Bonzini
2012-05-21  9:29 ` Kevin Wolf
2012-05-21 10:02   ` Paolo Bonzini
2012-05-21 10:32     ` Kevin Wolf
2012-05-21 11:02       ` Paolo Bonzini
2012-05-21 13:07         ` Kevin Wolf
2012-05-21 15:18           ` Paolo Bonzini
2012-05-21 13:13         ` Eric Blake
2012-05-21 12:20 ` Stefan Hajnoczi
2012-05-21 13:59 ` Luiz Capitulino
2012-05-21 14:09   ` Kevin Wolf
2012-05-21 14:16     ` Anthony Liguori
2012-05-21 14:17     ` Luiz Capitulino
2012-05-21 14:10   ` Anthony Liguori
2012-05-21 14:16     ` Luiz Capitulino
2012-05-21 14:19       ` Anthony Liguori
2012-05-21 14:26         ` Paolo Bonzini
2012-05-21 14:40           ` Anthony Liguori
2012-05-21 14:47             ` Paolo Bonzini [this message]
2012-05-21 15:44               ` Anthony Liguori
2012-05-21 15:55                 ` Paolo Bonzini
2012-05-21 14:17     ` Kevin Wolf
2012-05-21 14:39   ` Paolo Bonzini
2012-05-24 13:41 ` [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication] Paolo Bonzini
2012-05-24 14:00   ` Ori Mamluk
2012-05-24 14:19     ` Paolo Bonzini
2012-05-24 15:32       ` Dor Laor
2012-05-25  8:59         ` Paolo Bonzini
2012-05-24 16:57   ` Eric Blake
2012-05-25  8:48     ` Paolo Bonzini
2012-05-25 15:02       ` Eric Blake
2012-05-25  8:28   ` Stefan Hajnoczi
2012-05-25  8:42     ` Kevin Wolf
2012-05-25  9:43   ` Stefan Hajnoczi
2012-05-25 11:17     ` Paolo Bonzini
2012-05-25 12:09       ` Stefan Hajnoczi
2012-05-25 13:25         ` Paolo Bonzini
2012-05-25 16:57   ` Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBA5569.2030405@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=eblake@redhat.com \
    --cc=fsimonce@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.