Re: [PATCH 7/8] symbols: drop symbols-dummy.c

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.12.2025 16:19, Luca Fancellu wrote:
>>>> Now this is (to me at least) absurd: I'm removing a file, just to find the 
>>>> pipeline
>>>> fails because cppcheck doesn't like docs/misra/exclude-list.json 
>>>> containing a
>>>> reference to a non-existing file.
>>>>
>>>> I'll amend the commit with
>>>>
>>>> --- a/docs/misra/exclude-list.json
>>>> +++ b/docs/misra/exclude-list.json
>>>> @@ -170,10 +170,6 @@
>>>>            "comment": "Imported from Linux, ignore for now"
>>>>        },
>>>>        {
>>>> -            "rel_path": "common/symbols-dummy.c",
>>>> -            "comment": "The resulting code is not included in the final 
>>>> Xen binary, ignore for now"
>>>> -        },
>>>> -        {
>>>>            "rel_path": "crypto/*",
>>>>            "comment": "Origin is external and documented in 
>>>> crypto/README.source"
>>>>        },
>>>>
>>>> but I think such tidying should be optional.
>>>
>>> Can you share the error?
>>
>> + xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j16
>> ERROR: Issue with reading file 
>> /builds/xen-project/hardware/xen-staging/docs/misra/exclude-list.json: 
>> Malformed path: common/symbols-dummy.c refers to 
>> /builds/xen-project/hardware/xen-staging/xen/common/symbols-dummy.c that 
>> does not exists
> 
> Oh ok I see, seems to me a good feedback from the tool to keep everything 
> consistent.

Well. If I remove a file from the xen/ subtree, then seeing empty grep output 
on that
subtree should allow me to be sufficiently sure that no problematic (as in: 
breaking
the build) references have survived.

Plus while I agree that consistency is desirable to have here, is a stale file 
ref
really a reason to cause a build to fail? Wouldn't a warning suffice?

How many tools' behaviors can we (as developers, reviewers, and committers) 
keep in
mind when putting together otherwise simple changes?

Jan