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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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