From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Subject: Re: [PATCH for-4.5 v20 07/12] xl/remus: change bool to
	defbool
Date: Thu, 25 Sep 2014 16:03:27 -0400
Message-ID: <CAP8mzPOHJdm+h4dhXQWYDGjjMtEi=4Sk5BQREWWnANLUg8hOMA@mail.gmail.com>
References: <1411625784-4060-1-git-send-email-yanghy@cn.fujitsu.com>
	<1411625784-4060-8-git-send-email-yanghy@cn.fujitsu.com>
	<20140925192130.GG29663@laptop.dumpdata.com>
Reply-To: rshriram@cs.ubc.ca
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9110544220950168003=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20140925192130.GG29663@laptop.dumpdata.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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: ian.campbell@citrix.com, wency@cn.fujitsu.com, ian.jackson@eu.citrix.com, Jiang Yunhong <yunhong.jiang@intel.com>, eddie.dong@intel.com, xen-devel@lists.xen.org, Yang Hongyang <yanghy@cn.fujitsu.com>, laijs@cn.fujitsu.com
List-Id: xen-devel@lists.xenproject.org

--===============9110544220950168003==
Content-Type: multipart/alternative; boundary=90e6ba5bbc413aa2250503e94b47

--90e6ba5bbc413aa2250503e94b47
Content-Type: text/plain; charset=UTF-8

On Sep 25, 2014 3:21 PM, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
wrote:
>
> On Thu, Sep 25, 2014 at 02:16:19PM +0800, Yang Hongyang wrote:
> > Use defbool instead of bool for boolean flags in remus_info struct.
>
> While that change by itself looks OK, the change in 'libxl_types.idl'
> break the ABI.
>
> Could you say a bit of why that is OK? As in, would there had
> been in the past any users of this ABI that now would have issues with
this?
>

There were no users of the libxl Remus api in the past. Certainly not an
API level user like libvirt.

> Also, how important is this patch? Does it have to go in or
> can it be dropped from the patchset?
>

Well, this defbool thing came up as part of the feedback. Dropping this may
be of little consequence but there are new additions to the libxl Remus
struct (enable or disable net/disk buffer), that will break compatibility.
But we can't drop these patches.

> >

--90e6ba5bbc413aa2250503e94b47
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Sep 25, 2014 3:21 PM, &quot;Konrad Rzeszutek Wilk&quot; &=
lt;<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;=
 wrote:<br>
&gt;<br>
&gt; On Thu, Sep 25, 2014 at 02:16:19PM +0800, Yang Hongyang wrote:<br>
&gt; &gt; Use defbool instead of bool for boolean flags in remus_info struc=
t.<br>
&gt;<br>
&gt; While that change by itself looks OK, the change in &#39;libxl_types.i=
dl&#39;<br>
&gt; break the ABI.<br>
&gt;<br>
&gt; Could you say a bit of why that is OK? As in, would there had<br>
&gt; been in the past any users of this ABI that now would have issues with=
 this?<br>
&gt;<br></p>
<p dir=3D"ltr">There were no users of the libxl Remus api in the past. Cert=
ainly not an API level user like libvirt.</p>
<p dir=3D"ltr">&gt; Also, how important is this patch? Does it have to go i=
n or<br>
&gt; can it be dropped from the patchset?<br>
&gt;</p>
<p dir=3D"ltr">Well, this defbool thing came up as part of the feedback. Dr=
opping this may be of little consequence but there are new additions to the=
 libxl Remus struct (enable or disable net/disk buffer), that will break co=
mpatibility. But we can&#39;t drop these patches.</p>
<p dir=3D"ltr">&gt; &gt;</p>

--90e6ba5bbc413aa2250503e94b47--


--===============9110544220950168003==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============9110544220950168003==--