Re: [XEN PATCH v2 00/10] address violations of MISRA C:2012 Directive 4.10

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.09.2023 14:46, Simone Ballarin wrote:
> On 13/09/23 10:02, Jan Beulich wrote:
>> On 12.09.2023 11:36, Simone Ballarin wrote:
>>> Add or move inclusion guards to address violations of
>>> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
>>> to prevent the contents of a header file being included more than
>>> once").
>>>
>>> Inclusion guards must appear at the beginning of the headers
>>> (comments are permitted anywhere) and the #if directive cannot
>>> be used for other checks.
>>>
>>> Simone Ballarin (10):
>>>    misra: add deviation for headers that explicitly avoid guards
>>>    misra: modify deviations for empty and generated headers
>>>    misra: add deviations for direct inclusion guards
>>>    xen/arm: address violations of MISRA C:2012 Directive 4.10
>>>    xen/x86: address violations of MISRA C:2012 Directive 4.10
>>>    x86/EFI: address violations of MISRA C:2012 Directive 4.10
>>>    xen/common: address violations of MISRA C:2012 Directive 4.10
>>>    xen/efi: address violations of MISRA C:2012 Directive 4.10
>>>    xen: address violations of MISRA C:2012 Directive 4.10
>>>    x86/asm: address violations of MISRA C:2012 Directive 4.10
>>
>> Just to mention it here again for the entire series, seeing that despite
>> my earlier comments to this effect a few R-b have arrived: If private
>> headers need to gain guards (for, imo, no real reason), we first need to
>> settle on a naming scheme for these guards, such that guards used in
>> private headers aren't at risk of colliding with ones used headers
>> living in one of the usual include directories. IOW imo fair parts of
>> this series may need redoing.
>>
>> Jan
>>
> 
> My proposal is:
> - the relative path from "xen/arch" for files in this directory
>    (i.e. X86_X86_X86_MMCONFIG_H for "xen/arch/x86/x86_64/mmconfig.h";

X86_X86_64_MMCONFIG_H that is?

Yet then this scheme won't hold for xen/arch/include/asm/... ? It's also
not clear whether you're deliberately omitting leading/trailing underscores
here, which may be a way to distinguish private from global headers.

> - for the others, the entire path.

What exactly is "entire" here?

Jan