qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Osier Yang <jyang@redhat.com>,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	quintela@redhat.com
Subject: Re: [Qemu-devel] KVM call minutes for 2013-04-23
Date: Wed, 24 Apr 2013 11:43:22 -0400	[thread overview]
Message-ID: <20130424114322.7fd28560@redhat.com> (raw)
In-Reply-To: <20130424080321.GA20817@stefanha-thinkpad.redhat.com>

On Wed, 24 Apr 2013 10:03:21 +0200
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Tue, Apr 23, 2013 at 10:06:41AM -0600, Eric Blake wrote:
> > On 04/23/2013 08:45 AM, Juan Quintela wrote:
> > >   we can change "drive_mirror" to use a new command to see if there
> > >   are the new features.
> > 
> > drive-mirror changed in 1.4 to add optional buf-size parameter; right
> > now, libvirt is forced to limit itself to 1.3 interface (no buf-size or
> > granularity) because there is no introspection and no query-* command
> > that witnesses that the feature is present.  Idea was that we need to
> > add a new query-drive-mirror-capabilities (name subject to bikeshedding)
> > command into 1.5 that would let libvirt know that buf-size/granularity
> > is usable (done right, it would also prevent the situation of buf-size
> > being a write-only interface where it is set when starting the mirror
> > but can not be queried later to see what size is in use).
> > 
> > Unclear whether anyone was signing up to tackle the addition of a query
> > command counterpart for drive-mirror in time for 1.5.
> 
> Seems like the trivial solution is a query-command-capabilities QMP
> command.
> 
>   query-command-capabilities drive-mirror
>   => ['buf-size']
> 
> It should only be a few lines of code and can be used for other commands
> that add optional parameters in the future.  In other words:

IMO, a separate command is better because we'll return CommandNotFound error
if the command doesn't exist. If we add query-command-capabilities we'd need
a new error class, otherwise a client won't be able to tell if the command
passed as argument exists.

Besides, separate commands tend to be simpler; and we already have
query-migrate-capabilities anyway.

The only disadvantage is some duplication and an increase in the number of
commands, but I don't think this is avoidable.

> typedef struct mon_cmd_t {
>     ...
>     const char **capabilities; /* drive-mirror uses ["buf-size", NULL] */
> };
> 
> > > 
> > >   if we have a stable c-api we can do test cases that work. 
> > 
> > Having such a testsuite would make a stable C API more important.
> 
> Writing tests in Python has been productive, see qemu-iotests 041 and
> friends.  The tests spawn QEMU guests and use QMP to interact:

Good to know.

>   result = self.vm.qmp('query-block')
>   self.assert_qmp(result, 'return[0]/inserted/file', target_img)
> 
> Using this XPath-style syntax it's very easy to access the JSON.
> 
> QEMU users tend not to use C, except libvirt.  Even libvirt implements
> the QMP protocol dynamically and can handle optional arguments well.
> 
> I don't think a static C API makes sense when we have an extensible JSON
> protocol.  Let's use the extensibility to our advantage.

Agreed.

  reply	other threads:[~2013-04-24 15:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-23 14:45 [Qemu-devel] KVM call minutes for 2013-04-23 Juan Quintela
2013-04-23 16:06 ` Eric Blake
2013-04-24  8:03   ` Stefan Hajnoczi
2013-04-24 15:43     ` Luiz Capitulino [this message]
2013-04-24 15:21   ` Anthony Liguori
2013-04-24 15:30   ` Luiz Capitulino
2013-04-24 21:37   ` Eric Blake

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=20130424114322.7fd28560@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=jyang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).