From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c Date: Thu, 4 Feb 2016 10:51:35 +0000 Message-ID: <56B32D37.20006@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="us-ascii" Content-Transfer-Encoding: 7bit Return-path: 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 , ian.jackson@eu.citrix.com, wei.liu2@citrix.com, xen-devel@lists.xen.org, Olaf Hering List-Id: xen-devel@lists.xenproject.org On 04/02/16 10:19, 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: >> #define XC_WANT_COMPAT_EVTCHN_API >> #include >> #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. xenevtchn_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? Thinking about it, this looks like a better option. It is also more in line with the library naming. ~Andrew