From: Jules <junqing.wang@cs2c.com.cn>
To: Eric Blake <eblake@redhat.com>
Cc: pbonzini@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org,
owasserm@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/4] Curling: cmdline interface.
Date: Thu, 10 Oct 2013 10:52:52 +0800 [thread overview]
Message-ID: <1381373572.1741.16.camel@localhost> (raw)
In-Reply-To: <525545DE.2010505@redhat.com>
On Wed, 2013-10-09 at 06:02 -0600, Eric Blake wrote:
> [your emailer munged the reply, making it a bit hard to read. Are you
> set for plain-text-only mail to the list?]
Thanks VERY much for remind me that, I'm using another client now.
> On 10/09/2013 12:49 AM, junqing.wang@cs2c.com.cn wrote:
>
> > >> +++ b/hmp.c
> >>> @@ -1213,10 +1213,11 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
> >>> int detach = qdict_get_try_bool(qdict, "detach", 0);
> >>> int blk = qdict_get_try_bool(qdict, "blk", 0);
> >>> int inc = qdict_get_try_bool(qdict, "inc", 0);
> >>> + int ft = qdict_get_try_bool(qdict, "ft", 0);
> >>
> >> Why two spaces?
> >
> > To align the '=', I will remove them if you like.
>
> It's not a problem with me either way, other than we have a lot of code
> that doesn't care about alignment and consistently uses one space, and a
> fair amount of code where everything in a block of code is consistently
> aligned. But your patch was neither, in the context of the block it
> lives within - if you're going to align, then line up everything with
> the longest line 'int detach' (including blk and inc).
>
oh, I got it, you are right, I missed the longest line 'int detach ...'
I'm not going to align them.
> >
> > >
> >>> +++ b/qapi-schema.json
> >>> @@ -2420,7 +2420,8 @@
> >>> # Since: 0.14.0
> >>> ##
> >>> { 'command': 'migrate',
> >>> - 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' } }
> >>> + 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool',
> >>> + '*ft': 'bool' } }
> >>
> >> Missing documentation, including mention that the new option was only
> >> made available in 1.7. We still don't have introspection; is there some
> >> other means by which libvirt and other management apps can tell whether
> >> this feature is available?
> >
> > I'm not clear about how to do that, could you pls give me some hints, where to
> > add code and documentation.
>
> As for the documentation, qapi-schema.json has plenty of examples (look
> for a field with "(since 1.7)" as a hint for how to document an optional
> field added in a later release than the main struct).
I see. Thanks.
>
> As for the introspection, Amos Kong was most recently working on trying
> to add that (but missed the 1.6 deadline, and I haven't seen work on it
> since). Introspection is not a hard requirement, but it makes it harder
> for libvirt to know if it can use 'ft':true if there is no other
> 'query-*' command that it can call first that would give it a hint that
> this is a new enough qemu to support 'ft' during migration. Maybe even
> having something listed under query-migrate-capabilities would be
> sufficient (ie. modify the 'MigrationCapability' enum to advertise a new
> capability).
Adding a new migration capability is a work-around method. we turn on ft
by using the -f option instead of setting fault-tolerant-capability to
true. I hesitate to add it.
What about adding a query for the options of migration similar to
@query-command-line-options?
next prev parent reply other threads:[~2013-10-10 2:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 20:14 [Qemu-devel] [PATCH v2 0/4] Curling: KVM Fault Tolerance Jules Wang
2013-09-29 20:14 ` [Qemu-devel] [PATCH v2 1/4] Curling: add doc Jules Wang
2013-09-29 20:14 ` [Qemu-devel] [PATCH v2 2/4] Curling: cmdline interface Jules Wang
2013-09-30 22:16 ` Eric Blake
2013-10-09 6:49 ` junqing.wang
2013-10-09 12:02 ` Eric Blake
2013-10-10 2:52 ` Jules [this message]
2013-09-29 20:14 ` [Qemu-devel] [PATCH v2 3/4] Curling: the sender Jules Wang
2013-09-29 20:14 ` [Qemu-devel] [PATCH v2 4/4] Curling: the receiver Jules Wang
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=1381373572.1741.16.camel@localhost \
--to=junqing.wang@cs2c.com.cn \
--cc=eblake@redhat.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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.