|
|
|
|
|
|
|
|
|
|
xen-devel
[PATCH] [Linux] ia64, xencomm: fix 1028:6f7bda25a4de (Re: [Xen-devel] [I
>>> On 13.09.10 at 10:07, "KUWAMURA Shin'ya" <kuwa@xxxxxxxxxxxxxx> wrote:
> Hi Ian,
>
>>>>>> On Fri, 10 Sep 2010 18:51:23 +0100
>>>>>> Ian.Jackson@xxxxxxxxxxxxx(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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|