On 10.12.2024 15:48, Frediano Ziglio wrote:
> On Tue, Dec 10, 2024 at 2:44 PM Jan Beulich <jbeul...@suse.com> wrote:
>> On 10.12.2024 15:35, Frediano Ziglio wrote:
>>> On Tue, Dec 10, 2024 at 10:32 AM Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 22.11.2024 10:33, Frediano Ziglio wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/x86/include/boot/public/xen.h
>>>>> @@ -0,0 +1,28 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>> +
>>>>> +/* This header allows the inclusion of public xen.h */
>>>>> +
>>>>> +#ifndef BOOT__PUBLIC__XEN_H
>>>>> +#define BOOT__PUBLIC__XEN_H
>>>>> +
>>>>> +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ != 1
>>>>> +#error Unexpected defines
>>>>> +#endif
>>>>
>>>> What is this to guard against? We're in the Xen tree, building Xen.
>>>>
>>>
>>> In include/public/arch-x86/xen.h file there are these declarations:
>>>
>>> #if defined(__i386__)
>>> # ifdef __XEN__
>>> __DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
>>> __DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
>>> # endif
>>> #include "xen-x86_32.h"
>>> # ifdef __XEN__
>>> __UnDeF__ __DECL_REG_LO8
>>> __UnDeF__ __DECL_REG_LO16
>>> __DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
>>> __DeFiNe__ __DECL_REG_LO16(name) e ## name
>>> # endif
>>> #elif defined(__x86_64__)
>>> #include "xen-x86_64.h"
>>> #endif
>>>
>>> This header allows us to include that part without compiler errors due
>>> to __DeFiNe__ and __UnDeF__ not being C code.
>>
>> And why exactly can't 32-bit code simply include the compat variant of
>> the public header, which is being generated by processing those non-C
>> constructs?
>
> I suppose I could solve that specific issue in that way. Where are
> they generated?
include/Makefile generates them into include/compat/.
Jan
