Re: [PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3
On 06.12.2023 21:45, Andrew Cooper wrote: > On 05/12/2023 1:35 pm, Jan Beulich wrote: >> The rule demands that all array elements be initialized (or dedicated >> initializers be used). Introduce a small set of macros to allow doing so >> without unduly affecting use sites (in particular in terms of how many >> elements .matches[] actually has; right now there's no use of >> DMI_MATCH4(), so we could even consider reducing the array size to 3). >> >> Signed-off-by: Jan Beulich >> --- >> Of course a question is how many of these DMI table entries are in fact >> no longer applicable (e.g. because of naming 32-bit-only systems). >> Subsequently the table in dmi_scan.c itself may want cleaning up as >> well, yet I guess the question of stale entries is even more relevant >> there. >> --- >> v2: Make things also build with older gcc. > > > This is broken with Ubuntu > https://gitlab.com/xen-project/xen/-/jobs/5691138448 and you don't > appear to have been online today. And rightly so. I accidentally committed the v1 patch instead of the v2 one. > Unless you have a clever idea for a very prompt fix, it's going to need > reverting to cause GitlabCI to be usable for everyone else. I'll revert and put in the right change. I was online till about 15 minutes before you messaging me on Matrix. Jan
Re: [PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3
On 05/12/2023 1:35 pm, Jan Beulich wrote: > The rule demands that all array elements be initialized (or dedicated > initializers be used). Introduce a small set of macros to allow doing so > without unduly affecting use sites (in particular in terms of how many > elements .matches[] actually has; right now there's no use of > DMI_MATCH4(), so we could even consider reducing the array size to 3). > > Signed-off-by: Jan Beulich > --- > Of course a question is how many of these DMI table entries are in fact > no longer applicable (e.g. because of naming 32-bit-only systems). > Subsequently the table in dmi_scan.c itself may want cleaning up as > well, yet I guess the question of stale entries is even more relevant > there. > --- > v2: Make things also build with older gcc. This is broken with Ubuntu https://gitlab.com/xen-project/xen/-/jobs/5691138448 and you don't appear to have been online today. Unless you have a clever idea for a very prompt fix, it's going to need reverting to cause GitlabCI to be usable for everyone else. ~Andrew
Re: [PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3
On Tue, 5 Dec 2023, Jan Beulich wrote: > The rule demands that all array elements be initialized (or dedicated > initializers be used). Introduce a small set of macros to allow doing so > without unduly affecting use sites (in particular in terms of how many > elements .matches[] actually has; right now there's no use of > DMI_MATCH4(), so we could even consider reducing the array size to 3). > > Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini
Re: [PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3
Hi Jan, On 2023-12-05 14:35, Jan Beulich wrote: The rule demands that all array elements be initialized (or dedicated initializers be used). Introduce a small set of macros to allow doing so without unduly affecting use sites (in particular in terms of how many elements .matches[] actually has; right now there's no use of DMI_MATCH4(), so we could even consider reducing the array size to 3). Signed-off-by: Jan Beulich --- Of course a question is how many of these DMI table entries are in fact no longer applicable (e.g. because of naming 32-bit-only systems). Subsequently the table in dmi_scan.c itself may want cleaning up as well, yet I guess the question of stale entries is even more relevant there. --- v2: Make things also build with older gcc. Analyzed with ECLAIR for Rule 9.3: resolves all the violations related to DMI_MATCH. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)
[PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3
The rule demands that all array elements be initialized (or dedicated
initializers be used). Introduce a small set of macros to allow doing so
without unduly affecting use sites (in particular in terms of how many
elements .matches[] actually has; right now there's no use of
DMI_MATCH4(), so we could even consider reducing the array size to 3).
Signed-off-by: Jan Beulich
---
Of course a question is how many of these DMI table entries are in fact
no longer applicable (e.g. because of naming 32-bit-only systems).
Subsequently the table in dmi_scan.c itself may want cleaning up as
well, yet I guess the question of stale entries is even more relevant
there.
---
v2: Make things also build with older gcc.
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -19,11 +19,14 @@ static int __init cf_check force_bigsmp(
static const struct dmi_system_id __initconstrel bigsmp_dmi_table[] = {
- { force_bigsmp, "UNISYS ES7000-ONE", {
- DMI_MATCH(DMI_PRODUCT_NAME, "ES7000-ONE")
-}},
+ {
+ .ident = "UNISYS ES7000-ONE",
+ .callback = force_bigsmp,
+ DMI_MATCH1(
+ DMI_MATCH(DMI_PRODUCT_NAME, "ES7000-ONE")),
+ },
-{ }
+ { }
};
--- a/xen/arch/x86/hvm/quirks.c
+++ b/xen/arch/x86/hvm/quirks.c
@@ -36,42 +36,37 @@ static int __init cf_check check_port80(
{
.callback = dmi_hvm_deny_port80,
.ident= "Compaq Presario V6000",
-.matches = {
+ DMI_MATCH2(
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
-DMI_MATCH(DMI_BOARD_NAME, "30B7")
-}
+DMI_MATCH(DMI_BOARD_NAME, "30B7")),
},
{
.callback = dmi_hvm_deny_port80,
.ident= "HP Pavilion dv9000z",
-.matches = {
+ DMI_MATCH2(
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
-DMI_MATCH(DMI_BOARD_NAME, "30B9")
-}
+DMI_MATCH(DMI_BOARD_NAME, "30B9")),
},
{
.callback = dmi_hvm_deny_port80,
.ident= "HP Pavilion dv6000",
-.matches = {
+ DMI_MATCH2(
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
-DMI_MATCH(DMI_BOARD_NAME, "30B8")
-}
+DMI_MATCH(DMI_BOARD_NAME, "30B8")),
},
{
.callback = dmi_hvm_deny_port80,
.ident= "HP Pavilion tx1000",
-.matches = {
+ DMI_MATCH2(
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
-DMI_MATCH(DMI_BOARD_NAME, "30BF")
-}
+DMI_MATCH(DMI_BOARD_NAME, "30BF")),
},
{
.callback = dmi_hvm_deny_port80,
.ident= "Presario F700",
-.matches = {
+ DMI_MATCH2(
DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
-DMI_MATCH(DMI_BOARD_NAME, "30D3")
-}
+DMI_MATCH(DMI_BOARD_NAME, "30D3")),
},
{ }
};
--- a/xen/arch/x86/ioport_emulate.c
+++ b/xen/arch/x86/ioport_emulate.c
@@ -43,59 +43,51 @@ static const struct dmi_system_id __init
*/
{
.ident = "HP ProLiant DL3xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL3"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL3")),
},
{
.ident = "HP ProLiant DL5xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL5"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL5")),
},
{
.ident = "HP ProLiant DL7xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL7"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL7")),
},
{
.ident = "HP ProLiant ML3xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant ML3"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant ML3")),
},
{
.ident = "HP ProLiant ML5xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant ML5"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant ML5")),
},
{
.ident = "HP ProLiant BL2xx",
-.matches = {
+DMI_MATCH2(
DMI_MATCH(DMI_BIOS_VENDOR, "HP"),
-DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant BL2"),
-},
+DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant BL2")),
},
{
.ident = "HP ProLiant BL4xx",
-.matches = {
+
