On 09.02.2024 10:40, Julien Grall wrote:
> Replying on the v2 as well.
And answering here despite the respective question was raised on the
v1 thread: I'm certainly okay with the more detailed commit message.
A few nits, though:
> On 08/02/2024 15:56, Jan Beulich wrote:
>> On 08.02.2024 16:50, Nicola Vetrini wrote:
>>> These files contain several deliberate violations of MISRA C rules and
>>> they are not linked in the final Xen binary, therefore they can be exempted
>>> from MISRA compliance.
>
> I'd like the commit message to be expanded a little bit to explain which
> MISRA rules are a problem. This helped me to understand why we excluded
> rather than fixed.
>
> Base on the previous discussion, I would suggest:
>
> These files contain several deliberate violation of MISRA C rules such as:
violations
> * R20.12 on Arm for macros DEFINE and OFFSET, where the second
> argument of OFFSET is a macro and is used as a normal parameter and a
> stringification operand.
Is this really for Arm only?
> * R2.1 because the file is not linked That said it was decided to
> deviate the rule itselfed to deviate that aspect).
There look to be punctuation issues here. Also s/itselfed/itself/, and
the duplicate "deviate" is also a little odd to read (maybe "deal with"
or "address" in place of the 2nd instance).
> The files are also not linked in the final Xen binary, therefore they
> can be expempted from MISRA compliance.
Looks to duplicate what the latter half of the 2nd bullet point has.
If to be kept: s/expempted/exempted/.
>>> --- a/docs/misra/exclude-list.json
>>> +++ b/docs/misra/exclude-list.json
>>> @@ -101,6 +101,10 @@
>>> "rel_path": "arch/x86/efi/check.c",
>>> "comment": "The resulting code is not included in the final
>>> Xen binary, ignore for now"
>>> },
>>> + {
>>> + "rel_path": "arch/*/*/asm-offsets.c",
>>> + "comment": "The resulting code is not included in the final Xen
>>> binary, ignore for now"
>>> + },
>>> {
>>> "rel_path": "common/coverage/*",
>>> "comment": "Files to support gcov, ignore for now"
>>
>> ... something looks odd with indentation; can probably be adjusted
>> while committing.
>
> I am happy to take care of both the commit message and the indentation
> on commit.
Okay, I'll leave that to you then.
Jan
