From: Luiz Capitulino <lcapitulino@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Eric Blake <eblake@redhat.com>,
KVM devel mailing list <kvm@vger.kernel.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>,
Osier Yang <jyang@redhat.com>,
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.
WARNING: multiple messages have this Message-ID (diff)
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.
next prev parent reply other threads:[~2013-04-24 15:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 14:45 KVM call minutes for 2013-04-23 Juan Quintela
2013-04-23 14:45 ` [Qemu-devel] " Juan Quintela
2013-04-23 16:06 ` Eric Blake
2013-04-23 16:06 ` [Qemu-devel] " Eric Blake
2013-04-24 8:03 ` Stefan Hajnoczi
2013-04-24 8:03 ` Stefan Hajnoczi
2013-04-24 15:43 ` Luiz Capitulino [this message]
2013-04-24 15:43 ` Luiz Capitulino
2013-04-24 15:21 ` Anthony Liguori
2013-04-24 15:21 ` [Qemu-devel] " Anthony Liguori
2013-04-24 15:30 ` Luiz Capitulino
2013-04-24 15:30 ` Luiz Capitulino
2013-04-24 21:37 ` Eric Blake
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=eblake@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 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.