| Message ID | 1454580935-19200-1-git-send-email-ian.campbell@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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,
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
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
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 --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,
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(+)