Re: [Xen-devel] [PATCH 4/4] xen/percpu: Make DECLARE_PER_CPU() and __DEFINE_PER_CPU() common

[Juergen Gross <jgross@xxxxxxxx>]

On 29.07.19 20:03, Andrew Cooper wrote:
> On 29/07/2019 14:54, Jan Beulich wrote:
> > On 29.07.2019 15:23, Andrew Cooper wrote:
> > > On 29/07/2019 14:00, Jan Beulich wrote:
> > > > On 26.07.2019 23:08, Andrew Cooper wrote:
> > > > > --- a/xen/include/xen/percpu.h
> > > > > +++ b/xen/include/xen/percpu.h
> > > > > @@ -3,6 +3,12 @@
> > > > >     
> > > > >     #include <asm/percpu.h>
> > > > >     
> > > > > +#define DECLARE_PER_CPU(type, name) \
> > > > > +    extern __typeof__(type) per_cpu__ ## name
> > > > > +
> > > > > +#define __DEFINE_PER_CPU(attr, type, name) \
> > > > > +    attr __typeof__(type) per_cpu_ ## name
> > > > > +
> > > > >     /*
> > > > >      * Separate out the type, so (int[3], foo) works.
> > > > >      *
> > > > By moving things here you render stale the remainder of the
> > > > comment in context above: No per-arch symbol name prefix is going
> > > > to be possible anymore. I'm not against it, but this comment
> > > > would then want adjusting. What's not immediately clear to me is
> > > > whether the two-stage concatenation of an underscore each is then
> > > > still necessary.
> > > Yes it is still necessary.  See the TSS thread for why.
> > No, that thread doesn't explain it. From an initial look I think
> > two-stage expansion is still necessary
> It is about preventing 'name' being expanded, due to the mess with
> cpumask_scratch, which requires a ## at least at the top level.
>
> I personally think that fixing cpumask_scratch is the right way to go,
> but I specifically didn't touch that so as to avoid wreaking havoc with
> Juergen's core-scheduling series.
I appreciate that, but I don't think a large series like mine should
block efforts to make Xen cleaner.

Especially this case should be rather easy to handle, as there is no
change of the logic of the patches to be expected.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel