Re: [PATCH] stubdom: foreignmemory: Fix build after 0dbb4be739c5

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 13/07/2021 10:27, Juergen Gross wrote:
> On 13.07.21 11:20, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Commit 0dbb4be739c5 add the inclusion of xenctrl.h from private.h and
>> wreck the build in an interesting way:
>>
>> In file included from xen/stubdom/include/xen/domctl.h:39:0,
>>                   from xen/tools/include/xenctrl.h:36,
>>                   from private.h:4,
>>                   from minios.c:29:
>> xen/include/public/memory.h:407:5: error: expected
>> specifier-qualifier-list before ‘XEN_GUEST_HANDLE_64’
>>       XEN_GUEST_HANDLE_64(const_uint8) buffer;
>>       ^~~~~~~~~~~~~~~~~~~
>>
>> This is happening because xenctrl.h defines __XEN_TOOLS__ and therefore
>> the public headers will start to expose the non-stable ABI. However,
>> xen.h has already been included by a mini-OS header before hand. So
>> there is a mismatch in the way the headers are included.
>>
>> For now solve it in a very simple (and gross) way by including
>> xenctrl.h before the mini-os headers.
>>
>> Fixes: 0dbb4be739c5 ("tools/libs/foreignmemory: Fix PAGE_SIZE
>> redefinition error")
>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>
>> ---
>>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> I couldn't find a better way with would not result to revert the patch
>> (and break build on some system) or involve a longer rework of the
>> headers.
>
> Just adding a "#define __XEN_TOOLS__" before the #include statements
> doesn't work?

Not really, no.

libxenforeignmem has nothing at all to do with any Xen unstable
interfaces.  Including xenctrl.h in the first place was wrong, because
it is an unstable library.  By extension, the use of XC_PAGE_SIZE is
also wrong.

This all needs reverting/reworking to avoid making the stable libraries
depend on unstable ones, but in the short term we also need to unbreak
the CI.

~Andrew