From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH 07/10 V7] libxl: use the API to
	setup/teardown network buffering
Date: Mon, 3 Mar 2014 17:51:50 +0000
Message-ID: <21268.49462.367220.516477@mariner.uk.xensource.com>
References: <1392023972-24675-1-git-send-email-laijs@cn.fujitsu.com>
	<1392023972-24675-8-git-send-email-laijs@cn.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1392023972-24675-8-git-send-email-laijs@cn.fujitsu.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, FNST-Wen Congyang <wency@cn.fujitsu.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>, xen-devel@lists.xen.org, Shriram Rajagopalan <rshriram@cs.ubc.ca>, Roger Pau Monne <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

Lai Jiangshan writes ("[PATCH 07/10 V7] libxl: use the API to setup/teardown network buffering"):
> From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> If there is network buffering hotplug scripts, call
> libxl__remus_netbuf_setup() to setup the network
> buffering and libxl__remus_netbuf_teardown() to
> teardown network buffering.

> +    if (dss->remus_state) {
> +        /*
> +         * With Remus, if we reach this point, it means either
> +         * backup died or some network error occurred preventing us
> +         * from sending checkpoints. Teardown the network buffers and
> +         * release netlink resources.  This is an async op.
> +         */
> +        libxl__remus_teardown_initiate(egc, dss, rc);
> +        return;
> +    }

This patch seems plausible.  But I wonder if it might not be better to
provide a firmer interface between the remus code and the rest of the
save/restore machinery.  That is, have an explicit callback function
recorded by the save/restore code which is called back by the remus
machinery when it has done its work.  What do you think ?

I think having the flow of control spring off into libxl_remus.c and
magically come back by libxl_remus.c knowing to call
domain_suspend_done is rather opaque.

Thanks,
Ian.