> On 20 Dec 2023, at 08:41, Jan Beulich <[email protected]> wrote:
>
> On 20.12.2023 01:17, Stefano Stabellini wrote:
>> On Tue, 19 Dec 2023, Luca Fancellu wrote:
>>>> On 19 Dec 2023, at 11:05, Nicola Vetrini <[email protected]>
>>>> wrote:
>>>> On 2023-12-19 11:51, Nicola Vetrini wrote:
>>>>> On 2023-12-19 11:37, Jan Beulich wrote:
>>>>>> On 19.12.2023 10:02, Nicola Vetrini wrote:
>>>>>>> --- a/docs/misra/exclude-list.json
>>>>>>> +++ b/docs/misra/exclude-list.json
>>>>>>> @@ -209,6 +209,10 @@
>>>>>>> "rel_path": "include/acpi/acglobal.h",
>>>>>>> "comment": "Imported from Linux, ignore for now"
>>>>>>> },
>>>>>>> + {
>>>>>>> + "rel_path": "include/acpi/acmacros.h",
>>>>>>> + "comment": "Imported from Linux, ignore for now"
>>>>>>> + },
>>>>>> Together with what's already there (in context), wouldn't it better be
>>>>>> the entire directory then which is excluded, or at least all
>>>>>> include/acpi/ac*.h collectively (and perhaps also
>>>>>> include/acpi/platform/ac*.h)?
>>>>>> Jan
>>>>> +Cc Luca Fancellu
>>>>> Sure. I wasn't certain which files are imported from ACPI CA and which
>>>>> aren't.
>>>>> I'm also not sure whether "include/acpi/ac*.h" would be properly
>>>>> recognized by other tooling that uses exclude-list.json (only cppcheck I
>>>>> think). I Cc-ed Luca Fancellu on this.
>>>>
>>>> It occurred to me that it's surely ok to use "include/acpi/ac*" and
>>>> "include/acpi/platform/ac*".
>>>
>>> Yes I think it’s fine, it just come to my mind now that this could have the
>>> risk that if
>>> another file is added with ‘ac' prefix, even if it could be subject to
>>> MISRA compliance,
>>> it will be excluded.
>>>
>>> If that risk is negligible for the maintainer of that part, then it’s fine.
>>
>> I think it is OK either way, I'll let Jan pick his preference.
>
> It hasn't become clear to me what the benefit would be of omitting the
> trailing .h.
Yes, with the extension is better, the same as we already do here:
[...]
{
"rel_path": "common/un*.c”,
"comment": "unlz4.c implementation by Yann Collet, the others un* are from
Linux, ignore for now"
},
[...]
