[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public xen.h header



On Tue, Dec 10, 2024 at 2:44 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 10.12.2024 15:35, Frediano Ziglio wrote:
> > On Tue, Dec 10, 2024 at 10:32 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 22.11.2024 10:33, Frediano Ziglio wrote:
> >>> This allows to include other headers and avoid duplicated declarations.
> >>>
> >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxx>
> >>
> >> Again it's left unclear what the purpose / goal is.
> >>
> >
> > Reduce duplication avoiding duplicate declarations. The alternative
> > would be to duplicate them, which was proposed already and refused as
> > duplication was not good.
>
> Which declarations specifically?
>
> >>> --- /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?

> Jan

Frediano



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.