[PATCH] [Linux] ia64, xencomm: fix 1028:6f7bda25a4de (Re: [IA64] Weekly benchmark results [2010ww36])

["Jan Beulich" <JBeulich@novell.com>]

>>> On 13.09.10 at 10:07, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
> Hi Ian,
> 
>>>>>> On Fri, 10 Sep 2010 18:51:23 +0100
>>>>>> Ian.Jackson@eu.citrix.com(Ian Jackson)  said:
>> 
>> KUWAMURA Shin'ya writes ("[Xen-devel] [IA64] Weekly benchmark results 
> [2010ww36]"):
>> > - Linux-2.6.18-xen cannot be built:
>> >     In file included from 
> /linux-2.6.18-xen.hg/arch/ia64/xen/xcom_privcmd.c:27:
>> >     /linux-2.6.18-xen.hg/include/xen/interface/domctl.h:284: error: field 
> `cpumap' has incomplete type
>> >   This issue was fixed ad hoc.
>> 
>> If you'd like to send the ad-hoc fixes you used, that would be very
>> helpful.  If they're suitable for inclusion we'll commit them, and if
>> not they'll be good explanations of the bugs.
> 
> Thank you for your advice.
> I attached the patch. The cause is as follows:
> 
> 1028:6f7bda25a4de includes xen-unstable 21568:05bfc5a472b which
> moved struct xenctl_cpumap from domctl.h to xen.h.
> However, xcom_privcmd.c includes xen.h without __XEN__ or
> __XEN_TOOLS__, so struct xenctl_cpumap is invisible from
> xcom_privcmd.c.
> 
> This patch fixes by defining __XEN_TOOLS__ at the top of xcom_privcmd.c.
> But this causes a warning:
> 
> In file included from /linux-2.6.18-xen.hg/include/xen/interface/xen.h:30,
>                  from 
> /linux-2.6.18-xen.hg/include/xen/interface/arch-ia64.h:26,
>                  from include2/asm/xen/privop.h:16,
>                  from include2/asm/privop.h:14,
>                  from include2/asm/intrinsics.h:189,
>                  from include2/asm/bitops.h:14,
>                  from /linux-2.6.18-xen.hg/include/linux/bitops.h:9,
>                  from /linux-2.6.18-xen.hg/include/linux/kernel.h:15,
>                  from /linux-2.6.18-xen.hg/arch/ia64/xen/xcom_privcmd.c:22:
> /linux-2.6.18-xen.hg/include/xen/interface/xen-compat.h:34:1: warning: 
> "__XEN_INTERFACE_VERSION__" redefined
> <command line>:5:1: warning: this is the location of the previous definition

This doesn't seem to be the right (or a sufficient) fix then.

Even more, a few lines down in the same source file __XEN__
already gets #define-d, so the first choice imo would be to simply
move that definition up. Or does this cause any *more* problems
than the warning above (which I think needs to be dealt with
regardless)?

Jan