From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Hongyang Subject: Re: [PATCH v4 --for 4.6 COLOPre 21/25] tools/libxl: rename remus device to checkpoint device Date: Wed, 15 Jul 2015 21:38:13 +0800 Message-ID: <55A66245.30609@cn.fujitsu.com> References: <1436946351-21118-1-git-send-email-yanghy@cn.fujitsu.com> <1436946351-21118-22-git-send-email-yanghy@cn.fujitsu.com> <1436967160.32371.67.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436967160.32371.67.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, andrew.cooper3@citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 07/15/2015 09:32 PM, Ian Campbell wrote: > On Wed, 2015-07-15 at 15:45 +0800, Yang Hongyang wrote: >> tools/libxl/libxl_types.idl | 4 +- > >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl >> index e8d3647..1d676ef 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >> @@ -61,8 +61,8 @@ libxl_error = Enumeration("error", [ >> (-15, "LOCK_FAIL"), >> (-16, "JSON_CONFIG_EMPTY"), >> (-17, "DEVICE_EXISTS"), >> - (-18, "REMUS_DEVOPS_DOES_NOT_MATCH"), >> - (-19, "REMUS_DEVICE_NOT_SUPPORTED"), >> + (-18, "CHECKPOINT_DEVOPS_DOES_NOT_MATCH"), >> + (-19, "CHECKPOINT_DEVICE_NOT_SUPPORTED"), >> (-20, "VNUMA_CONFIG_INVALID"), >> (-21, "DOMAIN_NOTFOUND"), >> (-22, "ABORTED"), > > This is an API change, which I think we discussed before. Also missed this one, sorry. > > In <558BC6EE.60801@cn.fujitsu.com> you said you would add an extra patch > to deal with that, and I think that needs to come before this automatic will add the patch before the automatic renaming. > renaming so that there is no bisect hazard. I don't see any such patch > even after this point though (from grepping your colo-v8 branch). > > Ian. > > . > -- Thanks, Yang.