[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
- Date: Wed, 17 Sep 2025 13:59:18 +0000
- Accept-language: en-US, uk-UA, ru-RU
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zXPHv0eiWB6fWamkDKEiVENzRxdZ90Y2Irf6aq8NUXQ=; b=uTqHZAGPiSprcJcBKNltA1lRmakOwJPfwy06YEu8EDjlyH7pzstZpitTxLCrsN0MwsA4cVm9PliQWDofpt5TPVmUnXwHLC5vPwi8e423jo2U9ckalHztqktHdji5sLyCgESA2p0uv9ZgcrwCLqfjpBfdiXGwvHKy2QDUQ4+PWhrB2oz21Gzf9EXJN4JX+3nN3rgWpvlvl5teiFMe9e9NJVHKej7FHNkfb6ewaQD2sawZBdFrnzrgqJnH8t3KPMBRcfSWapYDFC0HyTUjc+C1qPCJnyIw0HgmAw777rb+T3Q2nVmMD782pCCQoMkthVHl3L8C9qiXuPofx0vIhKFxyQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RU9eCQUgmUXO+AkBJwRzbaU4TkKWmoQNsLoR+v1HvBmiz4hZLqEmEuL9sYAzxisbCbWEujJdq8pJJjcv+TMABA5RzhpQ3MfKWRBytm0oAB4OJdrQE16q/QhRNkaxhtPZMlJulgy7BYC+877zHI6D+Jb8Svlj99AccTixU6LbT4xx0uVPjS7VPKfz+AbHXeOw88QU6zJXNPzXEt8S/OjdaBNxGaTJ+Iz5RZQOa4B824lzdPZLM1CQcFNgj0uowVCLrf939Xq7vqYTb4W3pKOf+UfxtqBqO54TAWNMdsnUBv6Y1pAgfUlyS2ReGwqt1fG+FQFh1f2WvETPX9kyOH3Xsw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 17 Sep 2025 13:59:34 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHcJwfEWjVU7vF+102YDgRq9OEY77SV3fSAgABWKoCAAAe4AIABLJwA
- Thread-topic: [PATCH v2] misra: add deviation of Rule 2.1 for BUG() macro
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?
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.
> Whether (or why) moving would be required I don't know.
It shouldn't be moved. Nevermind.>
> Jan
Dmytro.
|
