Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
1 file changed, 1 insertion
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/xen/guest_access.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index af
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
Note that the rule does not apply to f because that parameter
is not used as an expression in the macro, but rather as an identifier.
---
xen/include/xen/irq.h | 2 +-
1 file
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
These local helpers could in principle be deviated, but the readability
and functionality are essentially unchanged by complying with the rule,
so I decided to modify the macro
here.
[1]
https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetr...@bugseng.com/
Nicola Vetrini (6):
automation/eclair: address violations of MISRA C Rule 20.7
xen/self-tests: address violations of MISRA rule 20.7
xen/guest_access: address
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
In this case the use of parentheses can detect misuses of the COMPILE_CHECK
macro for the fn argument that happen to pass the compile-time check
(see e.g. https://godbolt.org/z
, the risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
1 file changed, 8 insertion
On 2024-06-10 09:43, Jan Beulich wrote:
On 07.06.2024 22:13, Nicola Vetrini wrote:
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are
added
to the list of clean guidelines.
Why is 20.9 being mentioned here when ...
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b
ular macro argument and as an operand for
stringification in the expansion of CHECK_FIELD_.
This is deviated using a SAF-x-safe comment.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
docs/misra/safe.json | 8
xen/arch/x86/domain.c | 1 +
xen/arch/x86/domctl.
change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 447c1e6661d1..e2653f77eb2c 100644
patches.
Nicola Vetrini (3):
x86/domain: deviate violation of MISRA C Rule 20.12
automation/eclair_analysis: address remaining violations of MISRA C
Rule 20.12
automation/eclair_analysis: add more clean MISRA guidelines
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
automation
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are also
clean on x86, so they can be removed from there.
No functional change.
Signed-off-by: Nicola Vetrini
On 2024-06-04 08:08, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/shared.h
+++ b/xen/arch/x86/include/asm/shared.h
@@ -76,6 +76,7 @@ static inline void arch_set_##field(struct vcpu *v,
\
GET_SET_SHARED(unsigned long, max_pfn
On 2024-06-04 13:39, Oleksii K. wrote:
On Sat, 2024-06-01 at 21:13 +0200, Nicola Vetrini wrote:
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are
added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are
also
clean on x86, so
On 2024-06-03 23:24, Jan Beulich wrote:
On 03.06.2024 21:12, Nicola Vetrini wrote:
On 2024-06-03 20:52, Jan Beulich wrote:
On 03.06.2024 09:13, Nicola Vetrini wrote:
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR
On 2024-06-03 20:52, Jan Beulich wrote:
On 03.06.2024 09:13, Nicola Vetrini wrote:
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -483,6 +483,12
On 2024-06-03 08:39, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
MISRA C Rule 20.12 states: "A macro parameter used as an operand to
the # or ## operators, which is itself subject to further macro
replacement,
shall only be used as an operand to these oper
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -483,6 +483,12 @@ leads to a violation of the Rule are deviated."
-config=MC3R1.R20.12,m
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are also
clean on x86, so they can be removed from there.
No functional change.
Signed-off-by: Nicola Vetrini
---
+Cc
On 2024-06-01 16:37, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
Patches 1 to 4 address violations of MISRA C Rule 20.12 by deviating
certain
uses of some macros, while the last patch addresses some regressions
introduced
by the latest bitops series
Nicola Vetrini (5
On 2024-06-01 15:08, Andrew Cooper wrote:
On 01/06/2024 1:58 pm, Nicola Vetrini wrote:
On 2024-06-01 14:47, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
introduced new
On 2024-06-01 14:47, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
introduced new violations on previously clean rules 20.9 and 20.12.
The first is introduced because CONFIG_C
used both as a regular macro argument and as an operand for
stringification in the expansion of macro spin_lock_init_prof.
A SAF-x-safe deviation is introduced to justify this.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/safe.json | 8
xen/common/domain.c | 1 +
2 files
ular macro argument and as an operand for
stringification in the expansion of CHECK_FIELD_.
This is deviated using a SAF-x-safe comment.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/domain.c | 1 +
xen/arch/x86/domctl.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/xe
No functional change.
Fixes: ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
xen/include/xen/self-tests.h | 2 +-
2 files changed, 2 i
change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index cf62a874d928..f29db9e08248 100644
parameter and for token pasting the rule deliberately violated.
A SAF-x-safe comment is used to deviate the usage.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/shared.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/include/asm/shared.h
b/xe
Patches 1 to 4 address violations of MISRA C Rule 20.12 by deviating certain
uses of some macros, while the last patch addresses some regressions introduced
by the latest bitops series
Nicola Vetrini (5):
xen/domain: deviate violation of MISRA C Rule 20.12
x86/domain: deviate violation
On 2024-05-31 10:48, Andrew Cooper wrote:
On 31/05/2024 9:34 am, Andrew Cooper wrote:
On 31/05/2024 7:56 am, Nicola Vetrini wrote:
On 2024-05-31 03:14, Stefano Stabellini wrote:
On Fri, 24 May 2024, Andrew Cooper wrote:
Perform constant-folding unconditionally, rather than having
Ballarin
CC: Federico Serafini
CC: Nicola Vetrini
v2:
* Fall back to generic, not builtin.
* Extend the testing with multi-bit values.
* Use always_inline for x86
* Defer x86 optimisation to a later change
---
xen/arch/arm/include/asm/bitops.h | 2 +-
xen/arch/ppc/include/asm/bitops.h
On 2024-05-28 08:28, Jan Beulich wrote:
On 27.05.2024 16:53, Nicola Vetrini wrote:
Rule 8.4 states: "A compatible declaration shall be visible when
an object or function with external linkage is defined."
These variables are only referenced from asm modules, so they
need to
These files are used when debugging Xen, and are not meant to comply
with MISRA rules at the moment.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/exclude-list.json | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misra/exclude-list.json b/docs/misra
The parentheses in this regular expression should be doubly
escaped because they are undergo escaping twice.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/eclair_analysis
Hi all,
this series contains various miscellaneous changes to the ECLAIR and deviations
for MISRA rules
Nicola Vetrini (4):
docs/misra: exclude gdbsx from MISRA compliance
automation/eclair_analysis: avoid an ECLAIR warning about escaping
x86: address violations of MISRA C Rule 8.4
x86
e function must remain
extern.
Therefore, this function is deviated using a comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/traps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 468a03608102..99
s a result, they can be exempted using a comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
Adding the asmlinkage macro to variables is not appropriate, as
this pseudo-attribute may expand, for instance, to a different calling
convention in the future (e.g. stdcall)
---
xe
n the commit message, then
I am happy to update it on commit.
Cheers,
since Julien is ok with the patch, with the commit message he proposed,
I think this needs an R-by or an A-by in order to commit for 4.19.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
Some MISRA C rules already have no violations in Xen, so they can be
set as clean.
Reorder the rules in tagging.ecl according to version ordering
(i.e. sort -V) and split the configuration on multiple lines for
readability.
Signed-off-by: Nicola Vetrini
---
.../eclair_analysis/ECLAIR
This rule has no more violations in the codebase, so it can be
set as clean.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
On 2024-05-16 01:18, Stefano Stabellini wrote:
On Wed, 15 May 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses
for allowing
uses of these functions in the project.
The rules are also marked as clean as a consequence.
Signed-off-by: Nicola Vetrini
---
.../eclair_analysis/ECLAIR/deviations.ecl | 14 ++
.../eclair_analysis/ECLAIR/monitored.ecl | 2 ++
automation/eclair_analysis/ECLAIR
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/cpu/vpmu_amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index db2fa420e14a..97
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/mtrr.c | 2 +-
xen/arch/x86/hvm/rtc.c | 2 +-
xen/arch/x86/include/asm/hvm/save.h | 2 +-
3 files changed, 3 insertions(+), 3 deletion
n possibly alter the semantics of the passed-in macro parameter.
xlat_malloc_init is touched for consistency, despite the construct
being already deviated.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/x86_64/uaccess.h | 7 ---
1 file changed, 4 insert
gy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.
Nicola Vetrini (4):
x86/vpmu: address violations of MISRA C Rule 20.7
x86/hvm: address violations of MISRA C Rule 20.7
x86_64/uaccess: address violations of MISRA C Rule 20.7
x86_64/cpu_idl
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/x86_64/cpu_idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c
index fc
On 2024-05-01 21:54, Stefano Stabellini wrote:
On Mon, 29 Apr 2024, Nicola Vetrini wrote:
On 2024-04-25 02:28, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Nicola Vetrini wrote:
> > The count_args_ macro violates Rule 20.7, but it can't be made
> > compliant with Rule 20.7 w
Tag the rule as clean, as there are no more violations in the codebase since
93c27d54dd23 ("xen/arm: Fix MISRA regression on R1.1,
flexible array member not at the end").
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 inser
Tag the rule as clean, as there are no more violations in the codebase
since e8e8afee990a ("svm: Fix MISRA 8.2 violation").
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
using enum constants as controlling expressions
to comply with Rule 14.4.
Amend the comment in the enum definition to reflect the fact that
boolean uses of iommu_intremap are no longer allowed.
No functional change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-
Repositories under people/* only execute the analyze step if manually
triggered, but in order to avoid blocking the rest of the pipeline
if such step is not run, allow it to fail.
Reported-by: Andrew Cooper
Signed-off-by: Nicola Vetrini
---
See https://gitlab.com/xen-project/people/bugseng/xen
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-05-03 12:10, Jan Beulich wrote:
On 03.05.2024 09:29, Nicola Vetrini wrote:
On 2024-05-01 21:57, Stefano Stabellini wrote:
On Tue, 30 Apr 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parent
On 2024-05-01 21:57, Stefano Stabellini wrote:
On Tue, 30 Apr 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses
On 2024-04-30 17:13, Jan Beulich wrote:
On 30.04.2024 16:28, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/xen/pci_regs.h | 6 +++---
xen/include/xen/vpci.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/include/xen/pci_regs.h b/xen/i
n possibly alter the semantics of the passed-in macro parameter.
No functional chage.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- drop excess parentheses from val parameter.
---
xen/drivers/char/omap-uart.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
Somewhat surprisingly, the change in the tools directory is also needed,
otherwise
some CI build jobs fail (see e.g. [1]). This is not undefined behaviour
as long as the two d
gy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.
Patch 1/3 is derived from that of v1; patches 2 and 3 are new to this series.
Nicola Vetrini (3):
drivers: char: address violation of MISRA C Rule 20.7
xen/unaligned: address violation of MISRA C
e regression on R1.1 is resolved (see [1]).
[1] https://gitlab.com/xen-project/patchew/xen/-/jobs/6748211368
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
_t opt_smt;
extern int8_t opt_probe_port_aliases;
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-04-25 02:28, Stefano Stabellini wrote:
On Tue, 23 Apr 2024, Nicola Vetrini wrote:
The count_args_ macro violates Rule 20.7, but it can't be made
compliant with Rule 20.7 without breaking its functionality. Since
it's very unlikely for this macro to be misused, it is deviated
pe
form with named parameters:
violation: 2
(George just sent a patch to address the regressions of Rule 8.2.)
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-04-24 09:23, Jan Beulich wrote:
On 23.04.2024 17:12, Nicola Vetrini wrote:
--- a/xen/drivers/char/omap-uart.c
+++ b/xen/drivers/char/omap-uart.c
@@ -48,8 +48,9 @@
/* System configuration register */
#define UART_OMAP_SYSC_DEF_CONF 0x0d /* autoidle mode, wakeup is
enabled
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/hpet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 1db9c0b60ee0..5f456221c
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/debugreg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/debugreg.h
b/xen/arch/x86/include/asm/debugr
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/pci.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h
index 6b
n possibly alter the semantics of the passed-in macro parameter.
No functional chage.
Signed-off-by: Nicola Vetrini
---
xen/drivers/char/omap-uart.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/omap-uart.c b/xen/drivers/char/omap-uart.c
index 03
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9141912ae52d..87529db7d136 100644
--- a/xen/arc
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/acpi/power.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index c6
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/xen/page-defs.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/include/xen/page-defs.h b/xen/include/xen/page-defs.h
index 540f8b0b6452..68
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/common/spinlock.c | 2 +-
xen/include/xen/spinlock.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/spinlock.c b/xen/common/spinlo
gy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.
Nicola Vetrini (10):
libelf: address violations of MISRA C Rule 20.7
xen/page-defs: address violation of MISRA C Rule 20.7
automation/eclair_analysis: deviate macro count_args_ for MISRA Rul
The count_args_ macro violates Rule 20.7, but it can't be made
compliant with Rule 20.7 without breaking its functionality. Since
it's very unlikely for this macro to be misused, it is deviated.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/common/libelf/libelf-private.h | 2 +-
xen/include/xen/libelf.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/libelf/libelf-privat
not affect the
analysis. This new service is already supported by the current version of
ECLAIR.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Julien Grall
---
Changes in v3:
- Provide a better description
---
automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
1 file changed, 2
On 2024-04-19 11:21, Jan Beulich wrote:
On 19.04.2024 09:49, Nicola Vetrini wrote:
On 2024-04-19 09:35, Jan Beulich wrote:
On 19.04.2024 09:16, Nicola Vetrini wrote:
The ECLAIR service STD.emptrecd is being deprecated; hence, as a
preventive
measure, STD.anonstct is used here, which for Xen's
On 2024-04-19 09:35, Jan Beulich wrote:
On 19.04.2024 09:16, Nicola Vetrini wrote:
The ECLAIR service STD.emptrecd is being deprecated; hence, as a
preventive
measure, STD.anonstct is used here, which for Xen's purposes has
equivalent
functionality.
I'm sorry, but no, this still does
The ECLAIR service STD.emptrecd is being deprecated; hence, as a preventive
measure, STD.anonstct is used here, which for Xen's purposes has equivalent
functionality. This new service is already supported by the current version
of ECLAIR.
No functional change.
Signed-off-by: Nicola Vetrini
.
To avoid this, the construct is deviated with a text-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
docs/misra/safe.json | 8
xen/common/domain.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/docs/misra/safe.json b/docs/misra/safe.
On 2024-04-18 17:15, Jan Beulich wrote:
On 18.04.2024 17:00, Nicola Vetrini wrote:
On 2024-04-18 09:22, Jan Beulich wrote:
On 17.04.2024 16:51, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8
On 2024-04-18 17:10, Jan Beulich wrote:
On 17.04.2024 21:37, Nicola Vetrini wrote:
Refactor the first clauses so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
Note that the switch clause ending
On 2024-04-18 09:22, Jan Beulich wrote:
On 17.04.2024 16:51, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -44,8 +44,8 @@
-doc_end
-doc_begin="See Section \"6.19 Structures with
onsistency
between the
file and ECLAIR. I think they should be kept in sync because it
explain how
the tool doing the scanning behave.
My preference is to either split and only commit the rules now or wait
for the
ECLAIR change to happen.
Understood. Maybe the Bugseng team can provide the corresponding
ECLAIR/deviations.ecl changes
Sure, we can respin the patch with the appropriate deviation in place.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
hose
files for this guideline.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++
docs/misra/deviations.rst| 6 ++
2 files changed, 13 insertions(+)
diff --git a/automation/eclair_analy
A respin of the last two patches from the previous series.
No changes other than the different SAF comment id because SAF-4-safe was
already taken.
Nicola Vetrini (2):
xen/domctl: address violations of MISRA C Rule 16.2
eclair_analysis: deviate x86 emulator for Rule 16.2
automation
.
Convert fallthrough comments in other clauses to the pseudo-keyword
while at it.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
docs/misra/safe.json | 8
xen/common/domain.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/docs/misra/safe.json b/docs/misra
On 2024-04-17 16:57, Julien Grall wrote:
Hi Nicola,
On 17/04/2024 15:51, Nicola Vetrini wrote:
The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.
I am guessing this is not a new feature and the current ECLAIR version
is supporting it?
Cheers,
Yes
The service STD.emptrecd is in the process of being removed in favour
of STD.anonstct.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/eclair_analysis
On 2024-04-11 14:03, Andrew Cooper wrote:
On 09/04/2024 8:45 pm, Nicola Vetrini wrote:
On 2024-04-08 09:32, Jan Beulich wrote:
On 05.04.2024 11:14, Nicola Vetrini wrote:
Remove unneded blank lines between switch clauses.
"Unneeded" based on what? We're carefully trying
On 2024-04-10 21:35, Andrew Cooper wrote:
Resolves an R7.2 violation.
Thanks, I was going to suggest the same change. This will resolve the
failure of the CI MISRA analysis on GitLab.
Reviewed-by: Nicola Vetrini
Fixes: c286bb93d20c ("xen/spinlock: support higher number of cpus&quo
On 2024-04-09 16:02, Daniel P. Smith wrote:
On 4/5/24 05:14, Nicola Vetrini wrote:
Refactor the switch so that a violation of
MISRA C Rule 16.2 is resolved (A switch label shall only be used
when the most closely-enclosing compound statement is the body of
a switch statement).
Note
On 2024-04-08 09:57, Jan Beulich wrote:
On 05.04.2024 11:14, Nicola Vetrini wrote:
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -119,12 +119,12 @@ int hvm_hypercall(struct cpu_user_regs *regs)
(mode == 8 ? regs->rdi : regs-&
On 2024-04-08 09:39, Jan Beulich wrote:
On 05.04.2024 11:14, Nicola Vetrini wrote:
Refactor the switch so that a violation of MISRA C Rule 16.2 is
resolved
(A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement).
Note
On 2024-04-08 09:32, Jan Beulich wrote:
On 05.04.2024 11:14, Nicola Vetrini wrote:
Remove unneded blank lines between switch clauses.
"Unneeded" based on what? We're carefully trying to improve readability
of
large switch() statements by adding such blank lines (at least) between
On 2024-04-09 02:14, Stefano Stabellini wrote:
On Mon, 8 Apr 2024, Jan Beulich wrote:
On 05.04.2024 11:14, Nicola Vetrini wrote:
> Remove unneded blank lines between switch clauses.
NAK for this part again.
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2882,7 +2
The rule states:
"All identifiers used in the controlling expression of #if or #elif
preprocessing directives shall be #define'd before evaluation".
In this case, using defined(identifier) is a MISRA-compliant
way to achieve the same effect.
Signed-off-by: Nicola Vetrini
---
This i
Refactor the switch so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
The switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule 16.3.
Signed-off-by: Nico
impact
(the x86 emulator files and svm/emulate.c) are deviated, in order to have a
reasonable balance between code changes and deviations.
[1]
https://lore.kernel.org/xen-devel/99114c15a4256e6a0f39bd6de232ee4b8ad9b587.1698239734.git.nicola.vetr...@bugseng.com/
Nicola Vetrini (9):
x86/vlapic
ed exception to Rule 16.3.
Convert fallthrough comments in other clauses to the pseudo-keyword
while at it.
No functional change.
Signed-off-by: Nicola Vetrini
---
There is some degree of duplication here between the default clause
and the others, but I don't think there is a way to avoid it.
-
1 - 100 of 946 matches
Mail list logo
