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

[Jan Beulich <JBeulich@xxxxxxxx>]

On 29.07.2019 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.
> 
>> , but it could then be
>> _ ## name on the first and per_cpu ## name on the second (i.e.
>> no double underscore in the middle anymore).
> 
> Hmm, probably, but...
> 
>> Of course there may
>> be reasons why we actually _want_ a double underscore there.
> 
> ... I don't have the effort or energy - but most importantly, time - to
> rewrite Xen from scratch.
> 
> If there is a concrete reason why dropping the double underscore is
> good/necessary/other, then it should be present as its own patch, not
> crowbarred into an unrelated cleanup patch.
> 
> Until then, the inertia of "because its already like this" wins.

And this is all fine, as long as the comment in question continues
to reflect reality after this change.

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