qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/4] Curling: cmdline interface.


From: Jules
Subject: Re: [Qemu-devel] [PATCH v2 2/4] Curling: cmdline interface.
Date: Thu, 10 Oct 2013 10:52:52 +0800

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, address@hidden 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?







reply via email to

[Prev in Thread] Current Thread [Next in Thread]