diff mbox

tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

Message ID 1454580935-19200-1-git-send-email-ian.campbell@citrix.com
State New, archived
Headers show

Commit Message

Ian Campbell Feb. 4, 2016, 10:15 a.m. UTC
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 <xenevtchn.h>
    #include <xenctrl.h>

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 <olaf@aepfle.de>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
---
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?

Some sort of skank based on the header guard #defines, but that's
awful (and fragile).
---
 tools/libxc/include/xenctrl_compat.h | 2 ++
 tools/libxc/xc_evtchn_compat.c       | 1 +
 2 files changed, 3 insertions(+)

Comments

Ian Campbell Feb. 4, 2016, 10:19 a.m. UTC | #1
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 <xenevtchn.h>
>     #include <xenctrl.h>
> 
> 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 <olaf@aepfle.de>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> 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?

> 
> Some sort of skank based on the header guard #defines, but that's
> awful (and fragile).
> ---
>  tools/libxc/include/xenctrl_compat.h | 2 ++
>  tools/libxc/xc_evtchn_compat.c       | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl_compat.h
> b/tools/libxc/include/xenctrl_compat.h
> index 93ccadb..afc3d88 100644
> --- a/tools/libxc/include/xenctrl_compat.h
> +++ b/tools/libxc/include/xenctrl_compat.h
> @@ -51,7 +51,9 @@ void *xc_map_foreign_bulk(xc_interface *xch, uint32_t
> dom, int prot,
>  #ifdef XC_WANT_COMPAT_EVTCHN_API
>  
>  typedef struct xenevtchn_handle xc_evtchn;
> +#ifndef XC_BUILDING_COMPAT_EVTCHN_API
>  typedef xc_evtchn_port_or_error_t evtchn_port_or_error_t;
> +#endif
>  
>  xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
>                               unsigned open_flags);
> diff --git a/tools/libxc/xc_evtchn_compat.c
> b/tools/libxc/xc_evtchn_compat.c
> index 5d3e4ba..99da476 100644
> --- a/tools/libxc/xc_evtchn_compat.c
> +++ b/tools/libxc/xc_evtchn_compat.c
> @@ -6,6 +6,7 @@
>  #include <xenevtchn.h>
>  
>  #define XC_WANT_COMPAT_EVTCHN_API
> +#define XC_BUILDING_COMPAT_EVTCHN_API
>  #include "xenctrl.h"
>  
>  xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
Andrew Cooper Feb. 4, 2016, 10:51 a.m. UTC | #2
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 <xenevtchn.h>
>>     #include <xenctrl.h>
>>
>> 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 <olaf@aepfle.de>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> 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
Wei Liu Feb. 4, 2016, 11:08 a.m. UTC | #3
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:
> >     #define XC_WANT_COMPAT_EVTCHN_API
> >     #include <xenevtchn.h>
> >     #include <xenctrl.h>
> > 
> > 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 <olaf@aepfle.de>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> > 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?
> 

+1 for this
Olaf Hering Feb. 4, 2016, 11:25 a.m. UTC | #4
On Thu, Feb 04, Ian Campbell wrote:

> Reported-by: Olaf Hering <olaf@aepfle.de>

be05b53 + this change can be compiled in SLE11 and SLE12. Thanks.

Tested-by: Olaf Hering <olaf@aepfle.de>

Olaf
diff mbox

Patch

diff --git a/tools/libxc/include/xenctrl_compat.h b/tools/libxc/include/xenctrl_compat.h
index 93ccadb..afc3d88 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -51,7 +51,9 @@  void *xc_map_foreign_bulk(xc_interface *xch, uint32_t dom, int prot,
 #ifdef XC_WANT_COMPAT_EVTCHN_API
 
 typedef struct xenevtchn_handle xc_evtchn;
+#ifndef XC_BUILDING_COMPAT_EVTCHN_API
 typedef xc_evtchn_port_or_error_t evtchn_port_or_error_t;
+#endif
 
 xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,
                              unsigned open_flags);
diff --git a/tools/libxc/xc_evtchn_compat.c b/tools/libxc/xc_evtchn_compat.c
index 5d3e4ba..99da476 100644
--- a/tools/libxc/xc_evtchn_compat.c
+++ b/tools/libxc/xc_evtchn_compat.c
@@ -6,6 +6,7 @@ 
 #include <xenevtchn.h>
 
 #define XC_WANT_COMPAT_EVTCHN_API
+#define XC_BUILDING_COMPAT_EVTCHN_API
 #include "xenctrl.h"
 
 xc_evtchn *xc_evtchn_open(xentoollog_logger *logger,