[PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Ian Campbell]

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(+)

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,
-- 
2.1.4

Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Ian Campbell]

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,

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

Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Andrew Cooper]

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

Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Wei Liu]

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

Re: [PATCH] tools: libxc: do not redefine evtchn_port_or_error_t in xc_evtchn_compat.c

[Olaf Hering]

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