MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro names".
Update ECLAIR configuration to deviate clashes: specify the macros that
should be ignored. Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk
---
Changes in v4:
- fixed formatting (aligned l
On 7/31/25 10:20, Jan Beulich wrote:
> On 30.07.2025 23:47, Dmytro Prokopchuk1 wrote:
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -342,6 +342,12 @@ Deviations related to MISRA C:2012 Rules:
>> semantics that do not l
From: Nicola Vetrini
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specif
MISRA Rule 13.1: Initializer lists shall not contain persistent side
effects.
The violations occur because both the `GVA_INFO` and `TRACE_TIME` macro
expansions include expressions with persistent side effects introduced
via inline assembly.
In the case of `GVA_INFO`, the issue stems from the ini
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(void *)') to a function pointer type ('void (*)(void *)'
causes type incompatibility according to MISRA C Rule 11.1, which forbids
conversions between incompatible function pointer types.
The violation occurs
MISRA C Rule 5.5 states that: "Identifiers shall
be distinct from macro names".
Update ECLAIR configuration to deviate clashes:
specify the macros that should be ignored.
Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk
---
Changes in v3:
- removed deviation for
From: Nicola Vetrini
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specif
From: Nicola Vetrini
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in debug
nctional change; The compiled hypervisors are the same.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Dmytro Prokopchuk1
> ---
> CC: Anthony PERARD
> CC: Michal Orzel
> CC: Jan Beulich
> CC: Julien Grall
> CC: Roger Pau Monné
> CC: Stefano Stabellini
>
Signed-off-by: Dmytro Prokopchuk
---
xen/arch/arm/dm.c | 2 +-
xen/arch/arm/domctl.c | 2 +-
xen/arch/arm/gic-vgic.c| 26 +++---
xen/arch/arm/gic.c | 8 +++
xen/arch/arm/include/asm/cp
Signed-off-by: Dmytro Prokopchuk
---
xen/common/grant_table.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index cf131c43a1..9b8f0d87d3 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -12
Signed-off-by: Dmytro Prokopchuk
---
xen/arch/x86/irq.c| 8
xen/common/event_channel.c| 6 +++---
xen/drivers/passthrough/x86/hvm.c | 8
xen/include/xen/irq.h | 2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x8
Hello all!
The only purpose of this RFC is to receive comments from you on how to deal
with MISRA C Rule 5.5 violations in XEN.
The Rule states that: "Identifiers shall be distinct from macro names".
There are ~580 violations in ARM and ~3200 in x86 architectures.
The following macros violate thi
On 7/29/25 16:26, Jan Beulich wrote:
> On 29.07.2025 15:16, Nicola Vetrini wrote:
>> On 2025-07-29 15:09, Jan Beulich wrote:
>>> On 29.07.2025 15:02, Nicola Vetrini wrote:
>>>> On 2025-07-29 14:39, Jan Beulich wrote:
>>>>> On 29.07.2025 14:21, Dmyt
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(void *)') to a function pointer type ('void (*)(void *)'
causes type incompatibility according to MISRA C Rule 11.1, which forbids
conversions between incompatible function pointer types.
The violation occurs
On 7/29/25 11:04, Jan Beulich wrote:
> On 29.07.2025 00:15, Dmytro Prokopchuk1 wrote:
>> ECLAIR reports a non-compliant cast due to the presence
>> of the 'noreturn' attribute in the callee function.
>
> Which callee function? Which cast? Please be concrete. Yo
ECLAIR reports a non-compliant cast due to the presence
of the 'noreturn' attribute in the callee function.
The issue occurs when casting a function pointer with
the 'noreturn' attribute (void noreturn (*)(void *))
to a general function pointer type (void (*)(void *)).
Configure ECLAIR to treat 'n
On 7/28/25 21:03, Dmytro Prokopchuk wrote:
>
>
> On 7/28/25 20:43, Nicola Vetrini wrote:
>> On 2025-07-28 12:49, Andrew Cooper wrote:
>>> On 28/07/2025 10:56 am, Jan Beulich wrote:
>>>> On 27.07.2025 22:27, Dmytro Prokopchuk1 wrote:
>>>>&
On 7/28/25 20:43, Nicola Vetrini wrote:
> On 2025-07-28 12:49, Andrew Cooper wrote:
>> On 28/07/2025 10:56 am, Jan Beulich wrote:
>>> On 27.07.2025 22:27, Dmytro Prokopchuk1 wrote:
>>>> Explicitly cast 'halt_this_cpu' when passing it
>>&
On 7/28/25 11:06, Jan Beulich wrote:
> On 25.07.2025 23:34, Dmytro Prokopchuk1 wrote:
>> On 7/23/25 16:58, Jan Beulich wrote:
>>> On 23.07.2025 12:12, Dmytro Prokopchuk1 wrote:
>>>> --- a/xen/common/sched/core.c
>>>> +++ b/xen/common/sched/core.c
>
On 7/28/25 16:15, Jan Beulich wrote:
> On 28.07.2025 14:28, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 7/28/25 13:59, Andrew Cooper wrote:
>>> On 28/07/2025 11:38 am, Nicola Vetrini wrote:
>>>> On 2025-07-28 11:36, Jan Beulich wrote:
>>>>> On
On 7/28/25 12:56, Jan Beulich wrote:
> On 27.07.2025 22:27, Dmytro Prokopchuk1 wrote:
>> Explicitly cast 'halt_this_cpu' when passing it
>> to 'smp_call_function' to match the required
>> function pointer type '(void (*)(void *info))'.
&
On 7/28/25 13:59, Andrew Cooper wrote:
> On 28/07/2025 11:38 am, Nicola Vetrini wrote:
>> On 2025-07-28 11:36, Jan Beulich wrote:
>>> On 25.07.2025 18:24, Dmytro Prokopchuk1 wrote:
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviation
On 7/28/25 12:36, Jan Beulich wrote:
> On 25.07.2025 18:24, Dmytro Prokopchuk1 wrote:
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -142,6 +142,31 @@ Deviations related to MISRA C:2012 Rules:
>> memmove.
>>-
Explicitly cast 'halt_this_cpu' when passing it
to 'smp_call_function' to match the required
function pointer type '(void (*)(void *info))'.
Document and justify a MISRA C R11.1 deviation
(explicit cast).
Signed-off-by: Dmytro Prokopchuk
---
docs/misra/safe.json| 8
xen/arch/arm/sh
On 7/23/25 16:58, Jan Beulich wrote:
> On 23.07.2025 12:12, Dmytro Prokopchuk1 wrote:
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -568,6 +568,14 @@ C99 Undefined Behaviour 45: Pointers that do n
MISRA C Rule 5.5 states that: "Identifiers shall
be distinct from macro names".
Update ECLAIR configuration to deviate clashes:
specify the macros that should be ignored.
Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk
---
v1:
https://patchew.org/Xen/7e1c381d6f
These functions never return to their caller,
causing a violation of MISRA C Rule 2.1:
"A project shall not contain unreachable code".
Add the `noreturn' attribute to fix this.
No functional changes.
Signed-off-by: Dmytro Prokopchuk
---
xen/arch/arm/domain.c | 2 +-
xen/arch/arm/setup.c | 2
On 7/23/25 23:24, Stefano Stabellini wrote:
> On Wed, 23 Jul 2025, Dmytro Prokopchuk1 wrote:
>> Update ECLAIR configuration to consider guidelines as clean
>> so as to avoid regressions.
>>
>> Signed-off-by: Dmytro Prokopchuk
>
> Please provide a link to a cle
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to detect accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk
---
Test CI pipeline:
https://gitlab.com/xen-proje
On 7/21/25 13:34, Jan Beulich wrote:
> On 21.07.2025 12:27, Dmytro Prokopchuk1 wrote:
>> On 7/16/25 21:08, Dmytro Prokopchuk wrote:
>>> MISRA C Rule 5.5 states that: "Identifiers shall
>>> be distinct from macro names".
>>>
>>> Update
On 7/23/25 18:14, Jan Beulich wrote:
> On 23.07.2025 17:07, Dmytro Prokopchuk1 wrote:
>> Add MISRA C rules to the monitored set.
>> All these rules are 'accepted' for XEN, have zero or few violations,
>> and should be enabled for the ECLAIR scan.
>>
>>
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to prevent accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk
---
Changes in v2:
- updated commit message
---
a
Update ECLAIR configuration to consider guidelines as clean
so as to avoid regressions.
Signed-off-by: Dmytro Prokopchuk
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
b/automation/eclair_ana
On 7/23/25 16:34, Nicola Vetrini wrote:
> On 2025-07-23 15:30, Dmytro Prokopchuk1 wrote:
>> Add MISRA C rules to the monitored set.
>> All these rules are 'accepted' for XEN, have zero or few violations,
>> and should be enabled for the ECLAIR scan.
>>
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Signed-off-by: Dmytro Prokopchuk
---
Test CI:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1943607023
---
automation/eclair
Rule 18.3: "The relational operators >, >=, < and <=
shall not be applied to objects of pointer type
except where they point into the same object".
Update relational comparison to cast `text_start`
(void pointer) to `unsigned long`. This ensures the
comparison occurs between two values of the same
On 7/16/25 21:08, Dmytro Prokopchuk wrote:
> MISRA C Rule 5.5 states that: "Identifiers shall
> be distinct from macro names".
>
> Update ECLAIR configuration to deviate:
> - clashes in 'xen/include/xen/bitops.h';
> - clashes in 'xen/include/xen/irq.h';
> - clashes in 'xen/common/grant_table.c'.
On 7/18/25 12:17, Dmytro Prokopchuk wrote:
>
>
> On 7/18/25 08:31, Jan Beulich wrote:
>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 4/23/25 20:54, victorm.l...@amd.com wrote:
>>>> From: Nicola Vetrini
>>>>
&
On 7/18/25 08:31, Jan Beulich wrote:
> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 4/23/25 20:54, victorm.l...@amd.com wrote:
>>> From: Nicola Vetrini
>>>
>>> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
>&
On 4/23/25 20:54, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
> reserved identifier or reserved macro name") and R21.2 ("A reserved
> identifier or reserved macro name shall not be declared") violations
> are not problema
From: Nicola Vetrini
The definition of MISRA C Rule 12.2 ("The right hand operand of a shift
operator shall lie in the range zero to one less than the width in bits
of the essential type of the left hand operand") is concerned with the
essential type of an expression, while the C Undefined Behavi
On 7/17/25 09:45, Jan Beulich wrote:
> On 17.07.2025 03:09, Stefano Stabellini wrote:
>> On Wed, 16 Jul 2025, Dmytro Prokopchuk1 wrote:
>>> From: Nicola Vetrini
>>>
>>> The definition of MISRA C Rule 12.2 ("The right hand operand of a shift
>>>
MISRA C Rule 5.5 states that: "Identifiers shall
be distinct from macro names".
Update ECLAIR configuration to deviate:
- clashes in 'xen/include/xen/bitops.h';
- clashes in 'xen/include/xen/irq.h';
- clashes in 'xen/common/grant_table.c'.
Signed-off-by: Dmytro Prokopchuk
---
This patch makes MI
On 7/16/25 19:52, Nicola Vetrini wrote:
> On 2025-07-16 18:04, Dmytro Prokopchuk1 wrote:
>> On 7/15/25 13:50, Jan Beulich wrote:
>>> On 15.07.2025 12:07, Dmytro Prokopchuk1 wrote:
>>>> ARM only are:
>>>> -config=MC3A2.R5.5,reports+={deliberate,
>>&
On 7/15/25 13:50, Jan Beulich wrote:
> On 15.07.2025 12:07, Dmytro Prokopchuk1 wrote:
>> ARM only are:
>> -config=MC3A2.R5.5,reports+={deliberate,
>> "any_area(all_loc(file(^xen/include/xen/bitops\\.h$)))"}
>
> This one's probably fine.
>
Signed-off-by: Dmytro Prokopchuk
---
automation/gitlab-ci/analyze.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/gitlab-ci/analyze.yaml
b/automation/gitlab-ci/analyze.yaml
index 9102362601..d507210067 100644
--- a/automation/gitlab-ci/analyze.yaml
+++ b/automation/gitlab-ci/
From: Nicola Vetrini
The definition of MISRA C Rule 12.2 ("The right hand operand of a shift
operator shall lie in the range zero to one less than the width in bits
of the essential type of the left hand operand") is concerned with the
essential type of an expression, while the C Undefined Behavi
On 7/15/25 13:39, Jan Beulich wrote:
> On 15.07.2025 12:07, Dmytro Prokopchuk1 wrote:
>> ARM only are:
>> -config=MC3A2.R5.5,reports+={deliberate,
>> "any_area(all_loc(file(^xen/include/xen/bitops\\.h$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate,
>
"all_area(decl(name(update_gnttab_par))||macro(name(update_gnttab_par)))"}
-config=MC3A2.R5.5,reports+={deliberate,
"all_area(decl(name(pirq_cleanup_check))||macro(name(pirq_cleanup_check)))"}
Dmytro.
On 7/15/25 13:01, Jan Beulich wrote:
> On 15.07.2025 11:46, Dmytro Prok
l 2025, Nicola Vetrini wrote:
>>> On 2025-07-09 23:38, Dmytro Prokopchuk1 wrote:
>>>> MISRA C Rule 5.5 states that: "Identifiers shall
>>>> be distinct from macro names".
>>>>
>>>> Update ECLAIR configuration to deviate:
>&
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- boolean used as a numeric value.
The result of the '__isleap' macro is a boolean.
Suppress analyser tool finding.
The result of 'NOW() > timeout' is a boolean,
which is compared to a numeric va
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- boolean used as a numeric value.
The result of the '__isleap' macro is a boolean.
Suppress analyser tool finding.
The result of 'NOW() > timeout' is a boolean,
which is compared to a numeric va
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- boolean used as a numeric value.
The result of the '__isleap' macro is a boolean.
Use a ternary operator to replace it with a numeric value.
The result of 'NOW() > timeout' is a boolean,
which
From: Nicola Vetrini
MISRA C Rule 10.1 states:
"Operands shall not be of an inappropriate essential type"
The unary minus operator applied to an unsigned type(s) has
a semantics (wrap around) that is well-defined by the toolchains.
Thus, this operation is deemed safe.
No functional change.
Sig
;kind
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/dimaprkp4k/xen/ECLAIR_normal/deviate_10.1_rule/X86_64/10650467651/PROJECT.ecd;/by_service.html#service&kind
>
> BR, Dmytro.
>
> On 7/11/25 14:43, Dmytro Prokopchuk1 wrote:
>> Rule 10.
On 7/11/25 15:03, Jan Beulich wrote:
> On 11.07.2025 13:43, Dmytro Prokopchuk1 wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -773,7 +773,7 @@ static long
>> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>>
&g
vice&kind
there are still 2 violations.
And they can be easily fixed.
So, Jan and Stefano,
which approach should we select?
BR, Dmytro.
On 7/11/25 14:43, Dmytro Prokopchuk1 wrote:
> Rule 10.1: Operands shall not be of an
> inappropriate essential type
>
> The following are non-com
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- unary minus on unsigned type;
- boolean used as a numeric value.
Precede unary '-' operator with casting to signed type.
Replace numeric constant '-1UL' with '~0UL'.
Replace numeric constant '-1
CI tests:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1919687496
On 7/11/25 01:10, Dmytro Prokopchuk1 wrote:
> Rule 10.1: Operands shall not be of an
> inappropriate essential type
>
> The following are non-compliant:
> - unary minus on unsigned type;
> -
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- unary minus on unsigned type;
- boolean used as a numeric value.
Replace unary '-' operator with multiplying by '-1L' or '-1LL'.
Replace numeric constant '-1UL' with '~0UL'.
Replace numeric cons
Jan, I don't mind, you can adjust it.
Please, go ahead.
On 7/10/25 12:44, Dmytro Prokopchuk wrote:
> Yes, sure. I'll update commit message.
> Thanks!
>
> On 7/10/25 11:21, Jan Beulich wrote:
>> On 09.07.2025 23:38, Dmytro Prokopchuk1 wrote:
>>> Address
Yes, sure. I'll update commit message.
Thanks!
On 7/10/25 11:21, Jan Beulich wrote:
> On 09.07.2025 23:38, Dmytro Prokopchuk1 wrote:
>> Address a violation of MISRA C:2012 Rule 5.5:
>> "Identifiers shall be distinct from macro names".
>>
>> Repo
CI tests:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1917527911
On 7/10/25 00:38, Dmytro Prokopchuk1 wrote:
> This patch series eliminates/deviates MISRA C Rule 5.5 violations for ARM64.
>
> Thread discussion:
> https://patchew.org/Xen/cover.1751659393.git.dmytro
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/fdt-domain-build.h: non-compliant parameter 'copy_to_guest'
xen/include/xen/guest_access.h: non-compliant macro 'copy_to_guest'
Rename 'copy_to_guest' fu
This patch series eliminates/deviates MISRA C Rule 5.5 violations for ARM64.
Thread discussion:
https://patchew.org/Xen/cover.1751659393.git.dmytro._5fprokopch...@epam.com/
Changes in v2:
- fixed code alignment in "device-tree: address violation of MISRA C Rule 5.5"
- updated commit message in "i
MISRA C Rule 5.5 states that: "Identifiers shall
be distinct from macro names".
Update ECLAIR configuration to deviate:
- clashes in 'xen/include/xen/bitops.h';
- clashes in 'xen/include/xen/irq.h';
- clashes in 'xen/common/grant_table.c'.
Signed-off-by: Dmytro Prokopchuk
---
automation/eclair_
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/drivers/passthrough/iommu.c: non-compliant macro 'iommu_quarantine'
xen/include/xen/iommu.h: non-compliant variable 'iommu_quarantine'
There is a clash between funct
These external variables ('iommu_pt_cleanup_lock'
and 'iommu_pt_cleanup_list') are no longer used
in the codebase. Remove them.
Fixes: b5622eb627 (iommu: remove unused iommu_ops method and tasklet,
2020-09-22)
Signed-off-by: Dmytro Prokopchuk
---
xen/include/xen/iommu.h | 3 ---
1 file changed,
Pipeline:
https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/1907188989
On 7/4/25 23:39, Dmytro Prokopchuk1 wrote:
> This patch series fully eliminates MISRA C Rule 5.5
> violations for ARM64.
>
> The previous thread is here:
> https://lore.kerne
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/common/grant_table.c: non-compliant macro 'update_gnttab_par'
xen/common/grant_table.c: non-compliant macro 'parse_gnttab_limit'
The macros above are intended to dis
This patch series fully eliminates MISRA C Rule 5.5
violations for ARM64.
The previous thread is here:
https://lore.kernel.org/xen-devel/48c7830931a98b2bf70ef1509f309b262b9e5792.1745427770.git.victorm.l...@amd.com/
where that violation was proposed to be deviated.
Dmytro Prokopchuk (5):
gnttab:
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/fdt-domain-build.h: non-compliant parameter 'copy_to_guest'
xen/include/xen/guest_access.h: non-compliant macro 'copy_to_guest'
Rename 'copy_to_guest' fu
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/bitops.h: non-compliant function '__test_and_set_bit(int,
volatile void*)'
xen/include/xen/bitops.h: non-compliant macro '__test_and_set_bit'
xen/include
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/irq.h: non-compliant function `pirq_cleanup_check(struct pirq*,
struct domain*)'
xen/include/xen/irq.h: non-compliant macro `pirq_cleanup_check'
The pri
Address a violation of MISRA C:2012 Rule 5.5:
"Identifiers shall be distinct from macro names".
Reports for service MC3A2.R5.5:
xen/include/xen/iommu.h: non-compliant struct 'page_list_head'
xen/include/xen/mm.h: non-compliant macro 'page_list_head'
xen/drivers/passthrough/iommu.c: non-compliant m
Hello, All!
Do you have any comments on this patch?
Вoes it need any improvement?
BR, Dmytro.
On 6/24/25 04:19, Stefano Stabellini wrote:
> MISRA C Directive 4.10 states that "Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once".
>
> Ad
Hello, Nicola!
Would you mind if I take part of your patch (related to MISRA C Rule
21.1) and upstream it?
BR, Dmytro.
On 4/23/25 20:54, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
> reserved identifier or reserved macr
From: Federico Serafini
MISRA C Rule 21.6 states that "The Standard Library input/output
functions shall not be used".
Xen does not use the functions provided by the Standard Library,
uses -nostdlib to ensure this.
Xen implements a set of functions that share the same names as their
Standard Lib
Current script shows message:
Don't forget to add the subject and message to ...
Then perform:
git send-email -to xen-devel@lists.xenproject.org ...
which has wrong option '-to'.
It may be confused for user.
Set double dashes for longer options to avoid that.
Signed-off-by: Dmytro Prokopchuk
80 matches
Mail list logo
