Re: [Xen-devel] [PATCH v2.1 RESEND 00/19] libxl: asynchronous suspend

[Lai Jiangshan <laijs@xxxxxxxxxxxxxx>]

Ian Jackson

Should the remus netbuf&replicated-disks patchset be rebased on top of
this patchset?

Or I can send them as if this asynchronous suspend patchset is not applied.

Thanks,
Lai.

PS: git-am found some trailing whitespaces:

Applying: libxl: init: Provide a gc later in libxl_ctx_alloc
Applying: libxl: init: libxl__poller_init and _get take gc
Applying: libxl: events: const-correct *_inuse, *_isregistered
Applying: libxl: events: Provide libxl__xswait_*
Applying: libxl: events: Use libxl__xswait_* in spawn code
Applying: libxl: events: Provide libxl__ev_evtchn*
Applying: libxc: suspend: Rename, improve xc_suspend_evtchn_init
Applying: libxc: suspend: Fix suspend event channel locking
Applying: libxl: suspend: Async libxl__domain_suspend_callback
/home/laijs/work/xen/.git/rebase-apply/patch:87: trailing whitespace.
    [  3, 'scxA',   "suspend", [] ],         
warning: 1 line adds whitespace errors.
Applying: libxl: suspend: Async domain_suspend_callback_common
/home/laijs/work/xen/.git/rebase-apply/patch:102: trailing whitespace.
}    
/home/laijs/work/xen/.git/rebase-apply/patch:123: trailing whitespace.
}    
warning: 2 lines add whitespace errors.
Applying: libxl: suspend: Reorg domain_suspend_callback_common
Applying: libxl: suspend: New libxl__domain_pvcontrol_xspath
Applying: libxl: suspend: New domain_suspend_pvcontrol_acked
Applying: libxl: suspend: domain_suspend_callback_common xs errs
Applying: libxl: suspend: Async xenstore pvcontrol wait
Applying: libxl: suspend: Abolish usleeps in domain suspend wait
/home/laijs/work/xen/.git/rebase-apply/patch:38: trailing whitespace.
    rc = libxl__ev_time_register_rel(gc, &dss->guest_timeout, 
warning: 1 line adds whitespace errors.
Applying: libxl: suspend: Fix suspend wait corner cases
Applying: libxl: suspend: Async evtchn wait
Applying: libxl: suspend: Apply guest timeout in evtchn case



On 03/04/2014 10:56 PM, Ian Jackson wrote:
> This series removes the usleeps and waiting loops in libxl_dom.c and
> replaces them with event-callback code.
> 
> We want some additional libxl event facilities:
>     01/19 libxl: init: Provide a gc later in libxl_ctx_alloc
>     02/19 libxl: init: libxl__poller_init and _get take gc
>   a 03/19 libxl: events: const-correct *_inuse, *_isregistered
>  -  04/19 libxl: events: Provide libxl__xswait_*
>   a 05/19 libxl: events: Use libxl__xswait_* in spawn code
>  +  06/19 libxl: events: Provide libxl__ev_evtchn*
> 
> We need to clean up some unfortunate code in libxc:
>     07/19 libxc: suspend: Rename, improve xc_suspend_evtchn_init
>     08/19 libxc: suspend: Fix suspend event channel locking
> 
> We do some shuffling around of the libxl suspend control flow:
>  -  09/19 libxl: suspend: Async libxl__domain_suspend_callback
>     10/19 libxl: suspend: Async domain_suspend_callback_common
>     11/19 libxl: suspend: Reorg domain_suspend_callback_common
>     12/19 libxl: suspend: New libxl__domain_pvcontrol_xspath
>     13/19 libxl: suspend: New domain_suspend_pvcontrol_acked
> No functional change in those five.  These changes are broken down
> just to make the changes reviewable.
> 
> Finally, we can start to work on the event code, removing the bugs,
> usleeps and loops one at a time:
>     14/19 libxl: suspend: domain_suspend_callback_common xs errs
>     15/19 libxl: suspend: Async xenstore pvcontrol wait
>     16/19 libxl: suspend: Abolish usleeps in domain suspend wait
>     17/19 libxl: suspend: Fix suspend wait corner cases
>     18/19 libxl: suspend: Async evtchn wait
>     19/19 libxl: suspend: Apply guest timeout in evtchn case
> 
> Notes:
>    +   modified in v2
>    -   modified in v2 but only in commit message or comments
>    a   acked
> 
> I have tested v2 with a Debian pvops kernel (xenstore pvcontrol
> suspend signalling) and OpenSUSE 11 (event channel suspend
> signalling).  v2.1 is a rebase onto current staging.
> 
> I haven't really touched the Remus-specific code here but this series
> ought to be suitable for the Remus developers to base things on.
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel