Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.09.16 at 21:22, <julien.grall@xxxxxxx> wrote:

> 
> On 29/09/2016 12:11, Julien Grall wrote:
>> Hi Jan,
>>
>> On 28/09/2016 23:04, Jan Beulich wrote:
>>>>>> On 28.09.16 at 21:42, <julien.grall@xxxxxxx> wrote:
>>>> Hi Jan,
>>>>
>>>> On 28/09/2016 05:00, Jan Beulich wrote:
>>>>> For consumers not using (fully) C99-aware compilers, limit the number
>>>>> of places where tweaking of the headers would be necessary: Introduce
>>>>> and use xen_mk_ullong(), allowing its helper macro to be overridden at
>>>>> once.
>>>>>
>>>>> For now don't touch public/io/, which also has a few offenders.
>>>>>
>>>>> The need to include xen.h in hvm/e820.h demonstrates that it is a bad
>>>>> idea to include public headers first thing - arch/x86/hvm/mtrr.c needs
>>>>> adjustment just because of this.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>> ---
>>>>> I wonder why all those ARM constants carry the ULL suffix despite only
>>>>> two of them actually exceeding 32 significant bits.
>>>>
>>>> I am not the author of the code, but I think it was to declare all the
>>>> constants of a given set uniformed.
>>>>
>>>> For instance all the GUEST_* constants are used to define the layout of
>>>> the guest. This may be shuffle in this future (this is not part of ABI)
>>>
>>> Oh, they're in a Xen/tools only section (the #endif could really be
>>> annotated to help spot this) - in that case I could as well leave them
>>> alone. Any preference?
>>
>> Correct. I can send a patch to annotate the #endif.
> 
> It looks like that I did not reply to your question. Do we expect the 
> toolstack to always C99 standard? If not, then we should keep the 
> xen_mk_ullong.

We're even expecting GNUisms to be supported, like
__attribute__((aligned(...))). But since you said you're fine either
way, I guess I'll keep the patch as is.

Jan


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