Re: [Qemu-devel] qemu build fails on xen

[Paul Durrant]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:address@hidden
> Sent: 07 July 2015 09:48
> To: Stefano Stabellini
> Cc: Chen, Tiejun; address@hidden; address@hidden;
> address@hidden; address@hidden; Paul Durrant; Peter
> Maydell
> Subject: Re: qemu build fails on xen
> 
> On Tue, Jul 07, 2015 at 11:45:29AM +0300, Michael S. Tsirkin wrote:
> > The following error triggers on Fedora 22:
> >
> > In file included from /scm/qemu/include/hw/xen/xen_backend.h:4:0,
> >                  from hw/block/xen_disk.c:39:
> > /scm/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting
> types for ‘ioservid_t’
> >  typedef uint32_t ioservid_t;
> >                   ^
> > In file included from /usr/include/xen/hvm/params.h:24:0,
> >                  from /usr/include/xenctrl.h:46,
> >                  from /scm/qemu/include/hw/xen/xen_common.h:9,
> >                  from /scm/qemu/include/hw/xen/xen_backend.h:4,
> >                  from hw/block/xen_disk.c:39:
> > /usr/include/xen/hvm/hvm_op.h:255:18: note: previous declaration of
> ‘ioservid_t’ was here
> >  typedef uint16_t ioservid_t;
> >                   ^
> > /scm/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed
> > make: *** [hw/block/xen_disk.o] Error 1
> > make: *** Waiting for unfinished jobs....
> >
> > Reverting 3996e85c1822e05c50250f8d2d1e57b6bea1229d
> 
> Sorry - I meant reverting this commit fixes the problem.

Hmm. I'm not sure why the definition in xen_common.h is there. I guess it's 
probably for compatibility. It's clearly wrong though.

  Paul
 
> 
> 
> > Author: Paul Durrant <address@hidden>
> > Date:   Tue Jan 20 11:06:19 2015 +0000
> >
> >     Xen: Use the ioreq-server API when available
> >
> >
> > Looking at that header:
> >
> > #ifndef HVM_PARAM_BUFIOREQ_EVTCHN
> > #define HVM_PARAM_BUFIOREQ_EVTCHN 26
> > #endif
> >
> > #define IOREQ_TYPE_PCI_CONFIG 2
> >
> >
> > typedef uint32_t ioservid_t;
> >
> >
> > Are all polluting the global namespace, not to mention, violate the coding
> > style. Why not prefix them with Xen_, xen_ etc?
> >
> >
> > --
> > MST