Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 9/17/25 17:16, Jan Beulich wrote:
> On 17.09.2025 15:59, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 9/16/25 23:03, Jan Beulich wrote:
>>> On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
>>>>
>>>>
>>>> On 9/16/25 17:27, Jan Beulich wrote:
>>>>> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
>>>>>> --- a/docs/misra/deviations.rst
>>>>>> +++ b/docs/misra/deviations.rst
>>>>>> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>>>>>>            even when debug-only assertions like `ASSERT_UNREACHABLE()` 
>>>>>> are removed.
>>>>>>          - ECLAIR has been configured to ignore those statements.
>>>>>>
>>>>>> +   * - R2.1
>>>>>> +     - In the specific build configuration (when the config CONFIG_ACPI 
>>>>>> is not
>>>>>> +       defined) the 'BUG()' macro is intentionally used in the 
>>>>>> 'prepare_acpi()'
>>>>>> +       function in the header file 
>>>>>> 'xen/arch/arm/include/asm/domain_build.h'
>>>>>> +       defined as 'static inline' to trigger a runtime error if 
>>>>>> ACPI-related
>>>>>> +       features are used incorrectly.
>>>>>> +     - Tagged as `deliberate` for ECLAIR.
>>>>>
>>>>> I response to me outlining a deviation-less alternative you tried it out
>>>>> and said it works. Then why is the deviation still being put in place?
>>>>
>>>> Yes, that's true.
>>>> I started with that prepare_acpi() function and I tried to move it into
>>>> xen/include/xen/acpi.h header file under appropriate #ifdef:
>>>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/commit/d15cf91de92f1f8ec67911c51a13e7f095c1bcdd
>>>
>>> But an important part of my proposal was to have no #ifdef around
>>> the declaration, iirc. With that, no violation should result.
>> I don't understand, how it can help to avoid scanning by the Eclair?
>
> I didn't say it would. Scanning will always happen. The question is
> whether Eclair would flag anything.
>
>> In particular build configuration the "static inline" version of the
>> function will be present after preproccesor, and Eclair will scan it.
>>
>> Jan, please, explain your thought. I think, I missed something.
>
> If acpi_disabled is compile-time-constant false, all you need is a
> declaration for prepare_acpi(). The call to it will then be DCE-ed.
> No inline function, no #ifdef, no violation.
>
> Jan

Yeah... The key words were "No inline function". Now it's clear to me.
And it works fine for the 'prepare_acpi()' and
'gicv3_its_setup_collection()' functions.
No inline functions -> no violations. The Eclair is happy.
Instead of runtime checking we've got compile-time checking of the
functions invalid usage. Original idea is preserved.

Unfortunately, the function 'gicv3_do_LPI()' doesn't have a
compile-time-constant guard around it. Furthermore, it's assigned to the
callback pointer:

     .do_LPI              = gicv3_do_LPI,

It's possible to remove inline variant of this function,
put the following code inside #ifdef

     #ifdef CONFIG_HAS_ITS
         .do_LPI              = gicv3_do_LPI,
     #endif

and check callback pointer later

     if ( gic_hw_ops->do_LPI )
         gic_hw_ops->do_LPI(irq);

But we will lost the original idea (I mean having checking mechanism:
runtime or compile-time).

If you have some ideas, please let me know.
Otherwise, SAF comment should be created there.

Thanks,
Dmytro.