From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c Date: Thu, 4 Feb 2016 11:08:49 +0000 Message-ID: <20160204110849.GN23178@citrix.com> References: <1454580935-19200-1-git-send-email-ian.campbell@citrix.com> <1454581195.25207.151.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1454581195.25207.151.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, Olaf Hering , Andrew Cooper , ian.jackson@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, Feb 04, 2016 at 10:19:55AM +0000, Ian Campbell wrote: > Adding Olaf, I forgot that Reported-by doesn't turn into a Cc. > = > On Thu, 2016-02-04 at 10:15 +0000, Ian Campbell wrote: > > This file stradles the xenevtchn and libxc evtchn_compat worlds, and > > hence ends up with two evtchn_port_or_error_t typedefs which older > > gcc's (and the C standard) do not like. > > = > > Avoid this by gating the compat definition on a gate provided by the > > compat implementation. > > = > > Note that this would still be broken by an application which does: > > =A0=A0=A0=A0#define XC_WANT_COMPAT_EVTCHN_API > > =A0=A0=A0=A0#include > > =A0=A0=A0=A0#include > > = > > Which effectively means that an application must be ported over to > > xenevtchn in one go rather than incrementally (e.g. if it uses > > evtchn's for multiple purposes). Since the port is actually fairly > > mechanical I hope this is acceptable. > > = > > Reported-by: Olaf Hering > > Signed-off-by: Ian Campbell > > Cc: Andrew Cooper > > --- > > I'm not super happy about this approach, due to the caveat in the > > second half of the commit message. > > = > > Other approaches: > > = > > rename the libxenevtchn type, e.g.=A0=A0xenevtchn_port_or_error_t? > = > Thinking about this some more this might be the best approach. The type is > not used by qemu-xen, it is used by qemu-xen-traditional but we can fix > that in lockstep. > = > All of the in tree users are easy, of course. > = > Thoughts? > = +1 for this