Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross <jgross@xxxxxxxx>]

On 28/02/17 13:46, Jan Beulich wrote:
>>>> On 28.02.17 at 13:24, <JGross@xxxxxxxx> wrote:
>> On 28/02/17 12:11, Jan Beulich wrote:
>>>>>> On 28.02.17 at 11:34, <JGross@xxxxxxxx> wrote:
>>>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>>>> on the command line of the build instruction. This conflicts with
>>>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>>>> is set.
>>>
>>> Then that's what wants fixing. In fact it's questionable whether
>>> __XEN_TOOLS__ (or even __XEN__) getting defined there is
>>> appropriate.
>>
>> There are multiple libraries from the tools directory being compiled
>> for stubdoms.
> 
> Each if which should get appropriate settings.
> 
>>>> Just use #undef in this case to avoid the resulting warning.
>>>
>>> I think the lack of a warning in case of a collision is worse here.
>>> People should simply not define both the version symbol and
>>> either of __XEN__ or __XEN_TOOLS__.
>>
>> Would you be okay with:
>>
>> #if defined(__XEN_INTERFACE_VERSION__)
>>   #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
>>     #error ...
>>   #endif
>> #else
>>   #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
>> #endif
> 
> Well - see Ian's reply. If the values match (granted textually rather
> than by value), there should be no compiler warning in the first
> place.

Hmm, maybe this is the problem: the value from the command line is
(textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
#define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
pre-processor having replaced it already.

In case this makes sense, my suggestion seems to be appropriate, no?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel