All of lore.kernel.org
 help / color / mirror / Atom feed
* [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2
@ 2023-11-17  8:40 Federico Serafini
  2023-11-17  8:40 ` [XEN PATCH 1/5] xen/common: address " Federico Serafini
                   ` (4 more replies)
  0 siblings, 5 replies; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Jan Beulich, Andrew Cooper,
	George Dunlap, Julien Grall, Stefano Stabellini, Wei Liu

This patch series adds the missing parameter names to address violations of
MISRA C:2012 Rule 8.2. No functional changes are introduced.

Federico Serafini (5):
  xen/common: address violations of MISRA C:2012 Rule 8.2
  xen/serial: address violations of MISRA C:2012 Rule 8.2
  xen/sort: address violations of MISRA C:2012 Rule 8.2
  xen/vmap: address violations of MISRA C:2012 Rule 8.2
  xen/xalloc: address violations of MISRA C:2012 Rule 8.2

 xen/common/efi/runtime.c       |  2 +-
 xen/common/rangeset.c          |  6 +++---
 xen/common/spinlock.c          |  8 ++++----
 xen/common/stop_machine.c      |  4 ++--
 xen/common/tasklet.c           |  5 +++--
 xen/common/timer.c             |  4 ++--
 xen/include/xen/rangeset.h     |  4 ++--
 xen/include/xen/serial.h       | 30 +++++++++++++++---------------
 xen/include/xen/sort.h         |  4 ++--
 xen/include/xen/spinlock.h     |  2 +-
 xen/include/xen/stop_machine.h |  2 +-
 xen/include/xen/tasklet.h      |  7 ++++---
 xen/include/xen/timer.h        |  4 ++--
 xen/include/xen/vmap.h         |  6 +++---
 xen/include/xen/xmalloc.h      |  2 +-
 15 files changed, 46 insertions(+), 44 deletions(-)

-- 
2.34.1



^ permalink raw reply	[flat|nested] 22+ messages in thread

* [XEN PATCH 1/5] xen/common: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
@ 2023-11-17  8:40 ` Federico Serafini
  2023-11-18  2:59   ` Stefano Stabellini
  2023-11-17  8:40 ` [XEN PATCH 2/5] xen/serial: " Federico Serafini
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Jan Beulich, Andrew Cooper,
	George Dunlap, Julien Grall, Stefano Stabellini, Wei Liu

Add missing parameter names. No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 xen/common/efi/runtime.c       | 2 +-
 xen/common/rangeset.c          | 6 +++---
 xen/common/spinlock.c          | 8 ++++----
 xen/common/stop_machine.c      | 4 ++--
 xen/common/tasklet.c           | 5 +++--
 xen/common/timer.c             | 4 ++--
 xen/include/xen/rangeset.h     | 4 ++--
 xen/include/xen/spinlock.h     | 2 +-
 xen/include/xen/stop_machine.h | 2 +-
 xen/include/xen/tasklet.h      | 7 ++++---
 xen/include/xen/timer.h        | 4 ++--
 11 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 5cb7504c96..d952c3ba78 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -26,7 +26,7 @@ struct efi_rs_state {
 };
 
 struct efi_rs_state efi_rs_enter(void);
-void efi_rs_leave(struct efi_rs_state *);
+void efi_rs_leave(struct efi_rs_state *state);
 
 #ifndef COMPAT
 
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index f3baf52ab6..aa3a94e053 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -288,7 +288,7 @@ bool_t rangeset_overlaps_range(
 
 int rangeset_report_ranges(
     struct rangeset *r, unsigned long s, unsigned long e,
-    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt)
+    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt)
 {
     struct range *x;
     int rc = 0;
@@ -357,8 +357,8 @@ int rangeset_claim_range(struct rangeset *r, unsigned long size,
 }
 
 int rangeset_consume_ranges(struct rangeset *r,
-                            int (*cb)(unsigned long s, unsigned long e, void *,
-                                      unsigned long *c),
+                            int (*cb)(unsigned long s, unsigned long e,
+                                      void *ctxt, unsigned long *c),
                             void *ctxt)
 {
     int rc = 0;
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 7f453234a9..8fa3e253c0 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -305,7 +305,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
 }
 
 static void always_inline spin_lock_common(spinlock_t *lock,
-                                           void (*cb)(void *), void *data)
+                                           void (*cb)(void *data), void *data)
 {
     spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
     LOCK_PROFILE_VAR;
@@ -331,7 +331,7 @@ void _spin_lock(spinlock_t *lock)
     spin_lock_common(lock, NULL, NULL);
 }
 
-void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
+void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data)
 {
     spin_lock_common(lock, cb, data);
 }
@@ -498,8 +498,8 @@ struct lock_profile_anc {
     const char                *name;     /* descriptive string for print */
 };
 
-typedef void lock_profile_subfunc(
-    struct lock_profile *, int32_t, int32_t, void *);
+typedef void lock_profile_subfunc(struct lock_profile *data, int32_t type,
+    int32_t idx, void *par);
 
 extern struct lock_profile *__lock_profile_start;
 extern struct lock_profile *__lock_profile_end;
diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
index 3adbe380de..398cfd507c 100644
--- a/xen/common/stop_machine.c
+++ b/xen/common/stop_machine.c
@@ -46,7 +46,7 @@ struct stopmachine_data {
 
     unsigned int fn_cpu;
     int fn_result;
-    int (*fn)(void *);
+    int (*fn)(void *data);
     void *fn_data;
 };
 
@@ -73,7 +73,7 @@ static void stopmachine_wait_state(void)
  * mandatory to be called only on an idle vcpu, as otherwise active core
  * scheduling might hang.
  */
-int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu)
+int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
 {
     unsigned int i, nr_cpus;
     unsigned int this = smp_processor_id();
diff --git a/xen/common/tasklet.c b/xen/common/tasklet.c
index 3ad67b5c24..3649798e6b 100644
--- a/xen/common/tasklet.c
+++ b/xen/common/tasklet.c
@@ -199,7 +199,7 @@ static void migrate_tasklets_from_cpu(unsigned int cpu, struct list_head *list)
     spin_unlock_irqrestore(&tasklet_lock, flags);
 }
 
-void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
+void tasklet_init(struct tasklet *t, void (*func)(void *data), void *data)
 {
     memset(t, 0, sizeof(*t));
     INIT_LIST_HEAD(&t->list);
@@ -208,7 +208,8 @@ void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
     t->data = data;
 }
 
-void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
+void softirq_tasklet_init(struct tasklet *t,
+                          void (*func)(void *data), void *data)
 {
     tasklet_init(t, func, data);
     t->is_softirq = 1;
diff --git a/xen/common/timer.c b/xen/common/timer.c
index 0fddfa7487..bf7792dcb3 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -291,7 +291,7 @@ static bool active_timer(const struct timer *timer)
 
 void init_timer(
     struct timer *timer,
-    void        (*function)(void *),
+    void        (*function)(void *data),
     void         *data,
     unsigned int  cpu)
 {
@@ -441,7 +441,7 @@ void kill_timer(struct timer *timer)
 
 static void execute_timer(struct timers *ts, struct timer *t)
 {
-    void (*fn)(void *) = t->function;
+    void (*fn)(void *data) = t->function;
     void *data = t->data;
 
     t->status = TIMER_STATUS_inactive;
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 135f33f606..390f7b6082 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -68,7 +68,7 @@ bool_t __must_check rangeset_overlaps_range(
     struct rangeset *r, unsigned long s, unsigned long e);
 int rangeset_report_ranges(
     struct rangeset *r, unsigned long s, unsigned long e,
-    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
+    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt);
 
 /*
  * Note that the consume function can return an error value apart from
@@ -77,7 +77,7 @@ int rangeset_report_ranges(
  */
 int rangeset_consume_ranges(struct rangeset *r,
                             int (*cb)(unsigned long s, unsigned long e,
-                                      void *, unsigned long *c),
+                                      void *ctxt, unsigned long *c),
                             void *ctxt);
 
 /* Merge rangeset r2 into rangeset r1. */
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 16d933ae7e..785ef689a0 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -179,7 +179,7 @@ typedef struct spinlock {
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
-void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data);
+void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *data), void *data);
 void _spin_lock_irq(spinlock_t *lock);
 unsigned long _spin_lock_irqsave(spinlock_t *lock);
 
diff --git a/xen/include/xen/stop_machine.h b/xen/include/xen/stop_machine.h
index c63da1b309..0bbf71f112 100644
--- a/xen/include/xen/stop_machine.h
+++ b/xen/include/xen/stop_machine.h
@@ -14,6 +14,6 @@
  *
  * This can be thought of as a very heavy write lock, equivalent to
  * grabbing every spinlock in the kernel. */
-int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu);
+int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu);
 
 #endif /* __XEN_STOP_MACHINE_H__ */
diff --git a/xen/include/xen/tasklet.h b/xen/include/xen/tasklet.h
index 193acf8f42..59f2b522f3 100644
--- a/xen/include/xen/tasklet.h
+++ b/xen/include/xen/tasklet.h
@@ -21,7 +21,7 @@ struct tasklet
     bool_t is_softirq;
     bool_t is_running;
     bool_t is_dead;
-    void (*func)(void *);
+    void (*func)(void *data);
     void *data;
 };
 
@@ -59,8 +59,9 @@ void tasklet_schedule_on_cpu(struct tasklet *t, unsigned int cpu);
 void tasklet_schedule(struct tasklet *t);
 void do_tasklet(void);
 void tasklet_kill(struct tasklet *t);
-void tasklet_init(struct tasklet *t, void (*func)(void *), void *data);
-void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void *data);
+void tasklet_init(struct tasklet *t, void (*func)(void *data), void *data);
+void softirq_tasklet_init(struct tasklet *t,
+                          void (*func)(void *data), void *data);
 void tasklet_subsys_init(void);
 
 #endif /* __XEN_TASKLET_H__ */
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index 3a2a05c6de..fb28517515 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -29,7 +29,7 @@ struct timer {
     };
 
     /* On expiry, '(*function)(data)' will be executed in softirq context. */
-    void (*function)(void *);
+    void (*function)(void *data);
     void *data;
 
     /* CPU on which this timer will be installed and executed. */
@@ -57,7 +57,7 @@ struct timer {
  */
 void init_timer(
     struct timer *timer,
-    void        (*function)(void *),
+    void        (*function)(void *data),
     void         *data,
     unsigned int  cpu);
 
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [XEN PATCH 2/5] xen/serial: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
  2023-11-17  8:40 ` [XEN PATCH 1/5] xen/common: address " Federico Serafini
@ 2023-11-17  8:40 ` Federico Serafini
  2023-11-18  3:02   ` Stefano Stabellini
  2023-11-17  8:40 ` [XEN PATCH 3/5] xen/sort: " Federico Serafini
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Andrew Cooper, George Dunlap,
	Jan Beulich, Julien Grall, Stefano Stabellini, Wei Liu

Add missing parameter names. No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 xen/include/xen/serial.h | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index f0aff7ea76..fc3b4883a2 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -15,7 +15,7 @@
 struct cpu_user_regs;
 
 /* Register a character-receive hook on the specified COM port. */
-typedef void (*serial_rx_fn)(char, struct cpu_user_regs *);
+typedef void (*serial_rx_fn)(char c, struct cpu_user_regs *regs);
 void serial_set_rx_handler(int handle, serial_rx_fn fn);
 
 /* Number of characters we buffer for a polling receiver. */
@@ -63,31 +63,31 @@ struct serial_port {
 
 struct uart_driver {
     /* Driver initialisation (pre- and post-IRQ subsystem setup). */
-    void (*init_preirq)(struct serial_port *);
-    void (*init_irq)(struct serial_port *);
-    void (*init_postirq)(struct serial_port *);
+    void (*init_preirq)(struct serial_port *port);
+    void (*init_irq)(struct serial_port *port);
+    void (*init_postirq)(struct serial_port *port);
     /* Hook to clean up after Xen bootstrap (before domain 0 runs). */
-    void (*endboot)(struct serial_port *);
+    void (*endboot)(struct serial_port *port);
     /* Driver suspend/resume. */
-    void (*suspend)(struct serial_port *);
-    void (*resume)(struct serial_port *);
+    void (*suspend)(struct serial_port *port);
+    void (*resume)(struct serial_port *port);
     /* Return number of characters the port can hold for transmit,
      * or -EIO if port is inaccesible */
-    int (*tx_ready)(struct serial_port *);
+    int (*tx_ready)(struct serial_port *port);
     /* Put a character onto the serial line. */
-    void (*putc)(struct serial_port *, char);
+    void (*putc)(struct serial_port *port, char c);
     /* Flush accumulated characters. */
-    void (*flush)(struct serial_port *);
+    void (*flush)(struct serial_port *port);
     /* Get a character from the serial line: returns 0 if none available. */
-    int  (*getc)(struct serial_port *, char *);
+    int  (*getc)(struct serial_port *port, char *pc);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
-    int  (*irq)(struct serial_port *);
+    int  (*irq)(struct serial_port *port);
     /* Unmask TX interrupt */
-    void  (*start_tx)(struct serial_port *);
+    void  (*start_tx)(struct serial_port *port);
     /* Mask TX interrupt */
-    void  (*stop_tx)(struct serial_port *);
+    void  (*stop_tx)(struct serial_port *port);
     /* Get serial information */
-    const struct vuart_info *(*vuart_info)(struct serial_port *);
+    const struct vuart_info *(*vuart_info)(struct serial_port *port);
 };
 
 /* 'Serial handles' are composed from the following fields. */
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
  2023-11-17  8:40 ` [XEN PATCH 1/5] xen/common: address " Federico Serafini
  2023-11-17  8:40 ` [XEN PATCH 2/5] xen/serial: " Federico Serafini
@ 2023-11-17  8:40 ` Federico Serafini
  2023-11-18  3:05   ` Stefano Stabellini
  2023-11-20  9:02   ` Jan Beulich
  2023-11-17  8:40 ` [XEN PATCH 4/5] xen/vmap: " Federico Serafini
  2023-11-17  8:40 ` [XEN PATCH 5/5] xen/xalloc: " Federico Serafini
  4 siblings, 2 replies; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Andrew Cooper, George Dunlap,
	Jan Beulich, Julien Grall, Stefano Stabellini, Wei Liu

Add missing parameter names. No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 xen/include/xen/sort.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/sort.h b/xen/include/xen/sort.h
index 2f52ff85b9..1d5e3c5849 100644
--- a/xen/include/xen/sort.h
+++ b/xen/include/xen/sort.h
@@ -23,8 +23,8 @@
 extern gnu_inline
 #endif
 void sort(void *base, size_t num, size_t size,
-          int (*cmp)(const void *, const void *),
-          void (*swap)(void *, void *, size_t))
+          int (*cmp)(const void *key, const void *elem),
+          void (*swap)(void *a, void *b, size_t size))
 {
     /* pre-scale counters for performance */
     size_t i = (num / 2) * size, n = num * size, c, r;
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [XEN PATCH 4/5] xen/vmap: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
                   ` (2 preceding siblings ...)
  2023-11-17  8:40 ` [XEN PATCH 3/5] xen/sort: " Federico Serafini
@ 2023-11-17  8:40 ` Federico Serafini
  2023-11-18  3:06   ` Stefano Stabellini
  2023-11-17  8:40 ` [XEN PATCH 5/5] xen/xalloc: " Federico Serafini
  4 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Andrew Cooper, George Dunlap,
	Jan Beulich, Julien Grall, Stefano Stabellini, Wei Liu

Add missing parameter names. No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 xen/include/xen/vmap.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index b0f7632e89..2b7369e062 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -13,9 +13,9 @@ enum vmap_region {
 void vm_init_type(enum vmap_region type, void *start, void *end);
 
 void *__vmap(const mfn_t *mfn, unsigned int granularity, unsigned int nr,
-             unsigned int align, unsigned int flags, enum vmap_region);
+             unsigned int align, unsigned int flags, enum vmap_region type);
 void *vmap(const mfn_t *mfn, unsigned int nr);
-void vunmap(const void *);
+void vunmap(const void *va);
 
 void *vmalloc(size_t size);
 void *vmalloc_xen(size_t size);
@@ -23,7 +23,7 @@ void *vmalloc_xen(size_t size);
 void *vzalloc(size_t size);
 void vfree(void *va);
 
-void __iomem *ioremap(paddr_t, size_t);
+void __iomem *ioremap(paddr_t pa, size_t len);
 
 static inline void iounmap(void __iomem *va)
 {
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [XEN PATCH 5/5] xen/xalloc: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
                   ` (3 preceding siblings ...)
  2023-11-17  8:40 ` [XEN PATCH 4/5] xen/vmap: " Federico Serafini
@ 2023-11-17  8:40 ` Federico Serafini
  2023-11-18  3:06   ` Stefano Stabellini
  4 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-17  8:40 UTC (permalink / raw)
  To: xen-devel
  Cc: consulting, Federico Serafini, Andrew Cooper, George Dunlap,
	Jan Beulich, Julien Grall, Stefano Stabellini, Wei Liu

Add missing parameter names. No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 xen/include/xen/xmalloc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index 16979a117c..9ecddbff5e 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -63,7 +63,7 @@
     })
 
 /* Free any of the above. */
-extern void xfree(void *);
+extern void xfree(void *p);
 
 /* Free an allocation, and zero the pointer to it. */
 #define XFREE(p) do { \
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 1/5] xen/common: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 1/5] xen/common: address " Federico Serafini
@ 2023-11-18  2:59   ` Stefano Stabellini
  2023-11-20 13:55     ` Federico Serafini
  0 siblings, 1 reply; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-18  2:59 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Jan Beulich, Andrew Cooper, George Dunlap,
	Julien Grall, Stefano Stabellini, Wei Liu

On Fri, 17 Nov 2023, Federico Serafini wrote:
> diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
> index 3adbe380de..398cfd507c 100644
> --- a/xen/common/stop_machine.c
> +++ b/xen/common/stop_machine.c
> @@ -46,7 +46,7 @@ struct stopmachine_data {
>  
>      unsigned int fn_cpu;
>      int fn_result;
> -    int (*fn)(void *);
> +    int (*fn)(void *data);
>      void *fn_data;
>  };

At least one of the possible function used here calls the parameter
"arg", see take_cpu_down. But I don't think it is a MISRA requirement to
also harmonize those?


> @@ -73,7 +73,7 @@ static void stopmachine_wait_state(void)
>   * mandatory to be called only on an idle vcpu, as otherwise active core
>   * scheduling might hang.
>   */
> -int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu)
> +int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>  {
>      unsigned int i, nr_cpus;
>      unsigned int this = smp_processor_id();
> diff --git a/xen/common/tasklet.c b/xen/common/tasklet.c
> index 3ad67b5c24..3649798e6b 100644
> --- a/xen/common/tasklet.c
> +++ b/xen/common/tasklet.c
> @@ -199,7 +199,7 @@ static void migrate_tasklets_from_cpu(unsigned int cpu, struct list_head *list)
>      spin_unlock_irqrestore(&tasklet_lock, flags);
>  }
>  
> -void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
> +void tasklet_init(struct tasklet *t, void (*func)(void *data), void *data)
>  {
>      memset(t, 0, sizeof(*t));
>      INIT_LIST_HEAD(&t->list);
> @@ -208,7 +208,8 @@ void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
>      t->data = data;
>  }
>  
> -void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
> +void softirq_tasklet_init(struct tasklet *t,
> +                          void (*func)(void *data), void *data)
>  {
>      tasklet_init(t, func, data);
>      t->is_softirq = 1;
> diff --git a/xen/common/timer.c b/xen/common/timer.c
> index 0fddfa7487..bf7792dcb3 100644
> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -291,7 +291,7 @@ static bool active_timer(const struct timer *timer)
>  
>  void init_timer(
>      struct timer *timer,
> -    void        (*function)(void *),
> +    void        (*function)(void *data),
>      void         *data,
>      unsigned int  cpu)
>  {
> @@ -441,7 +441,7 @@ void kill_timer(struct timer *timer)
>  
>  static void execute_timer(struct timers *ts, struct timer *t)
>  {
> -    void (*fn)(void *) = t->function;
> +    void (*fn)(void *data) = t->function;
>      void *data = t->data;
>  
>      t->status = TIMER_STATUS_inactive;
> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
> index 135f33f606..390f7b6082 100644
> --- a/xen/include/xen/rangeset.h
> +++ b/xen/include/xen/rangeset.h
> @@ -68,7 +68,7 @@ bool_t __must_check rangeset_overlaps_range(
>      struct rangeset *r, unsigned long s, unsigned long e);
>  int rangeset_report_ranges(
>      struct rangeset *r, unsigned long s, unsigned long e,
> -    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
> +    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt);

Also here some of the functions use "arg" instead of ctxt


>  /*
>   * Note that the consume function can return an error value apart from
> @@ -77,7 +77,7 @@ int rangeset_report_ranges(
>   */
>  int rangeset_consume_ranges(struct rangeset *r,
>                              int (*cb)(unsigned long s, unsigned long e,
> -                                      void *, unsigned long *c),
> +                                      void *ctxt, unsigned long *c),
>                              void *ctxt);

Also here some of the functions use "dom" like irq_remove_cb.


But I actually like the patch as is, so if that's OK from a MISRA point
of view then I would give my reviewed-by.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 2/5] xen/serial: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 2/5] xen/serial: " Federico Serafini
@ 2023-11-18  3:02   ` Stefano Stabellini
  0 siblings, 0 replies; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-18  3:02 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Andrew Cooper, George Dunlap, Jan Beulich,
	Julien Grall, Stefano Stabellini, Wei Liu

On Fri, 17 Nov 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 3/5] xen/sort: " Federico Serafini
@ 2023-11-18  3:05   ` Stefano Stabellini
  2023-11-20  9:02   ` Jan Beulich
  1 sibling, 0 replies; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-18  3:05 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Andrew Cooper, George Dunlap, Jan Beulich,
	Julien Grall, Stefano Stabellini, Wei Liu

On Fri, 17 Nov 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
> ---
>  xen/include/xen/sort.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/xen/sort.h b/xen/include/xen/sort.h
> index 2f52ff85b9..1d5e3c5849 100644
> --- a/xen/include/xen/sort.h
> +++ b/xen/include/xen/sort.h
> @@ -23,8 +23,8 @@
>  extern gnu_inline
>  #endif
>  void sort(void *base, size_t num, size_t size,
> -          int (*cmp)(const void *, const void *),
> -          void (*swap)(void *, void *, size_t))
> +          int (*cmp)(const void *key, const void *elem),
> +          void (*swap)(void *a, void *b, size_t size))
>  {
>      /* pre-scale counters for performance */
>      size_t i = (num / 2) * size, n = num * size, c, r;


Ideally we should also fix swap_memory_node, swap_mmio_handler


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 4/5] xen/vmap: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 4/5] xen/vmap: " Federico Serafini
@ 2023-11-18  3:06   ` Stefano Stabellini
  0 siblings, 0 replies; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-18  3:06 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Andrew Cooper, George Dunlap, Jan Beulich,
	Julien Grall, Stefano Stabellini, Wei Liu

On Fri, 17 Nov 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 5/5] xen/xalloc: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 5/5] xen/xalloc: " Federico Serafini
@ 2023-11-18  3:06   ` Stefano Stabellini
  0 siblings, 0 replies; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-18  3:06 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Andrew Cooper, George Dunlap, Jan Beulich,
	Julien Grall, Stefano Stabellini, Wei Liu

On Fri, 17 Nov 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
> 
> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-17  8:40 ` [XEN PATCH 3/5] xen/sort: " Federico Serafini
  2023-11-18  3:05   ` Stefano Stabellini
@ 2023-11-20  9:02   ` Jan Beulich
  2023-11-20 13:13     ` Federico Serafini
  1 sibling, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2023-11-20  9:02 UTC (permalink / raw)
  To: Federico Serafini
  Cc: consulting, Andrew Cooper, George Dunlap, Julien Grall,
	Stefano Stabellini, Wei Liu, xen-devel

On 17.11.2023 09:40, Federico Serafini wrote:
> --- a/xen/include/xen/sort.h
> +++ b/xen/include/xen/sort.h
> @@ -23,8 +23,8 @@
>  extern gnu_inline
>  #endif
>  void sort(void *base, size_t num, size_t size,
> -          int (*cmp)(const void *, const void *),
> -          void (*swap)(void *, void *, size_t))
> +          int (*cmp)(const void *key, const void *elem),

Why "key" and "elem" here, but ...

> +          void (*swap)(void *a, void *b, size_t size))

... "a" and "b" here? The first example of users of sort() that I'm
looking at right now (x86/extable.c) is consistent in its naming.

Jan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-20  9:02   ` Jan Beulich
@ 2023-11-20 13:13     ` Federico Serafini
  2023-11-20 16:00       ` Jan Beulich
  0 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-20 13:13 UTC (permalink / raw)
  To: Jan Beulich
  Cc: consulting, Andrew Cooper, George Dunlap, Julien Grall,
	Stefano Stabellini, Wei Liu, xen-devel

On 20/11/23 10:02, Jan Beulich wrote:
> On 17.11.2023 09:40, Federico Serafini wrote:
>> --- a/xen/include/xen/sort.h
>> +++ b/xen/include/xen/sort.h
>> @@ -23,8 +23,8 @@
>>   extern gnu_inline
>>   #endif
>>   void sort(void *base, size_t num, size_t size,
>> -          int (*cmp)(const void *, const void *),
>> -          void (*swap)(void *, void *, size_t))
>> +          int (*cmp)(const void *key, const void *elem),
> 
> Why "key" and "elem" here, but ...
> 
>> +          void (*swap)(void *a, void *b, size_t size))
> 
> ... "a" and "b" here? The first example of users of sort() that I'm
> looking at right now (x86/extable.c) is consistent in its naming.
> 

On the Arm side there are {cmp,swap}_memory_node() and
{cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
and "_a"/"_b" for the swap.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 1/5] xen/common: address violations of MISRA C:2012 Rule 8.2
  2023-11-18  2:59   ` Stefano Stabellini
@ 2023-11-20 13:55     ` Federico Serafini
  2023-11-21  0:02       ` Stefano Stabellini
  0 siblings, 1 reply; 22+ messages in thread
From: Federico Serafini @ 2023-11-20 13:55 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: xen-devel, consulting, Jan Beulich, Andrew Cooper, George Dunlap,
	Julien Grall, Wei Liu

On 18/11/23 03:59, Stefano Stabellini wrote:
> On Fri, 17 Nov 2023, Federico Serafini wrote:
>> diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
>> index 3adbe380de..398cfd507c 100644
>> --- a/xen/common/stop_machine.c
>> +++ b/xen/common/stop_machine.c
>> @@ -46,7 +46,7 @@ struct stopmachine_data {
>>   
>>       unsigned int fn_cpu;
>>       int fn_result;
>> -    int (*fn)(void *);
>> +    int (*fn)(void *data);
>>       void *fn_data;
>>   };
> 
> At least one of the possible function used here calls the parameter
> "arg", see take_cpu_down. But I don't think it is a MISRA requirement to
> also harmonize those?
> 
> 
>> @@ -73,7 +73,7 @@ static void stopmachine_wait_state(void)
>>    * mandatory to be called only on an idle vcpu, as otherwise active core
>>    * scheduling might hang.
>>    */
>> -int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu)
>> +int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>>   {
>>       unsigned int i, nr_cpus;
>>       unsigned int this = smp_processor_id();
>> diff --git a/xen/common/tasklet.c b/xen/common/tasklet.c
>> index 3ad67b5c24..3649798e6b 100644
>> --- a/xen/common/tasklet.c
>> +++ b/xen/common/tasklet.c
>> @@ -199,7 +199,7 @@ static void migrate_tasklets_from_cpu(unsigned int cpu, struct list_head *list)
>>       spin_unlock_irqrestore(&tasklet_lock, flags);
>>   }
>>   
>> -void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
>> +void tasklet_init(struct tasklet *t, void (*func)(void *data), void *data)
>>   {
>>       memset(t, 0, sizeof(*t));
>>       INIT_LIST_HEAD(&t->list);
>> @@ -208,7 +208,8 @@ void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
>>       t->data = data;
>>   }
>>   
>> -void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
>> +void softirq_tasklet_init(struct tasklet *t,
>> +                          void (*func)(void *data), void *data)
>>   {
>>       tasklet_init(t, func, data);
>>       t->is_softirq = 1;
>> diff --git a/xen/common/timer.c b/xen/common/timer.c
>> index 0fddfa7487..bf7792dcb3 100644
>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -291,7 +291,7 @@ static bool active_timer(const struct timer *timer)
>>   
>>   void init_timer(
>>       struct timer *timer,
>> -    void        (*function)(void *),
>> +    void        (*function)(void *data),
>>       void         *data,
>>       unsigned int  cpu)
>>   {
>> @@ -441,7 +441,7 @@ void kill_timer(struct timer *timer)
>>   
>>   static void execute_timer(struct timers *ts, struct timer *t)
>>   {
>> -    void (*fn)(void *) = t->function;
>> +    void (*fn)(void *data) = t->function;
>>       void *data = t->data;
>>   
>>       t->status = TIMER_STATUS_inactive;
>> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
>> index 135f33f606..390f7b6082 100644
>> --- a/xen/include/xen/rangeset.h
>> +++ b/xen/include/xen/rangeset.h
>> @@ -68,7 +68,7 @@ bool_t __must_check rangeset_overlaps_range(
>>       struct rangeset *r, unsigned long s, unsigned long e);
>>   int rangeset_report_ranges(
>>       struct rangeset *r, unsigned long s, unsigned long e,
>> -    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
>> +    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt);
> 
> Also here some of the functions use "arg" instead of ctxt
> 
> 
>>   /*
>>    * Note that the consume function can return an error value apart from
>> @@ -77,7 +77,7 @@ int rangeset_report_ranges(
>>    */
>>   int rangeset_consume_ranges(struct rangeset *r,
>>                               int (*cb)(unsigned long s, unsigned long e,
>> -                                      void *, unsigned long *c),
>> +                                      void *ctxt, unsigned long *c),
>>                               void *ctxt);
> 
> Also here some of the functions use "dom" like irq_remove_cb.
> 
> 
> But I actually like the patch as is, so if that's OK from a MISRA point
> of view then I would give my reviewed-by.

Yes, this is OK for MISRA.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-20 13:13     ` Federico Serafini
@ 2023-11-20 16:00       ` Jan Beulich
  2023-11-21  0:04         ` Stefano Stabellini
  0 siblings, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2023-11-20 16:00 UTC (permalink / raw)
  To: Federico Serafini
  Cc: consulting, Andrew Cooper, George Dunlap, Julien Grall,
	Stefano Stabellini, Wei Liu, xen-devel

On 20.11.2023 14:13, Federico Serafini wrote:
> On 20/11/23 10:02, Jan Beulich wrote:
>> On 17.11.2023 09:40, Federico Serafini wrote:
>>> --- a/xen/include/xen/sort.h
>>> +++ b/xen/include/xen/sort.h
>>> @@ -23,8 +23,8 @@
>>>   extern gnu_inline
>>>   #endif
>>>   void sort(void *base, size_t num, size_t size,
>>> -          int (*cmp)(const void *, const void *),
>>> -          void (*swap)(void *, void *, size_t))
>>> +          int (*cmp)(const void *key, const void *elem),
>>
>> Why "key" and "elem" here, but ...
>>
>>> +          void (*swap)(void *a, void *b, size_t size))
>>
>> ... "a" and "b" here? The first example of users of sort() that I'm
>> looking at right now (x86/extable.c) is consistent in its naming.
>>
> 
> On the Arm side there are {cmp,swap}_memory_node() and
> {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
> and "_a"/"_b" for the swap.

So - re-raising a question Stefano did raise - is Misra concerned about
such discrepancies? If yes, _all_ instances need harmonizing. If not, I
see no reason to go with misleading names here.

Jan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 1/5] xen/common: address violations of MISRA C:2012 Rule 8.2
  2023-11-20 13:55     ` Federico Serafini
@ 2023-11-21  0:02       ` Stefano Stabellini
  2023-11-23  8:59         ` Jan Beulich
  0 siblings, 1 reply; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-21  0:02 UTC (permalink / raw)
  To: Federico Serafini
  Cc: Stefano Stabellini, xen-devel, consulting, Jan Beulich,
	Andrew Cooper, George Dunlap, Julien Grall, Wei Liu

On Mon, 19 Nov 2023, Federico Serafini wrote:
> On 18/11/23 03:59, Stefano Stabellini wrote:
> > On Fri, 17 Nov 2023, Federico Serafini wrote:
> > > diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
> > > index 3adbe380de..398cfd507c 100644
> > > --- a/xen/common/stop_machine.c
> > > +++ b/xen/common/stop_machine.c
> > > @@ -46,7 +46,7 @@ struct stopmachine_data {
> > >         unsigned int fn_cpu;
> > >       int fn_result;
> > > -    int (*fn)(void *);
> > > +    int (*fn)(void *data);
> > >       void *fn_data;
> > >   };
> > 
> > At least one of the possible function used here calls the parameter
> > "arg", see take_cpu_down. But I don't think it is a MISRA requirement to
> > also harmonize those?
> > 
> > 
> > > @@ -73,7 +73,7 @@ static void stopmachine_wait_state(void)
> > >    * mandatory to be called only on an idle vcpu, as otherwise active core
> > >    * scheduling might hang.
> > >    */
> > > -int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu)
> > > +int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
> > >   {
> > >       unsigned int i, nr_cpus;
> > >       unsigned int this = smp_processor_id();
> > > diff --git a/xen/common/tasklet.c b/xen/common/tasklet.c
> > > index 3ad67b5c24..3649798e6b 100644
> > > --- a/xen/common/tasklet.c
> > > +++ b/xen/common/tasklet.c
> > > @@ -199,7 +199,7 @@ static void migrate_tasklets_from_cpu(unsigned int
> > > cpu, struct list_head *list)
> > >       spin_unlock_irqrestore(&tasklet_lock, flags);
> > >   }
> > >   -void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
> > > +void tasklet_init(struct tasklet *t, void (*func)(void *data), void
> > > *data)
> > >   {
> > >       memset(t, 0, sizeof(*t));
> > >       INIT_LIST_HEAD(&t->list);
> > > @@ -208,7 +208,8 @@ void tasklet_init(struct tasklet *t, void (*func)(void
> > > *), void *data)
> > >       t->data = data;
> > >   }
> > >   -void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void
> > > *data)
> > > +void softirq_tasklet_init(struct tasklet *t,
> > > +                          void (*func)(void *data), void *data)
> > >   {
> > >       tasklet_init(t, func, data);
> > >       t->is_softirq = 1;
> > > diff --git a/xen/common/timer.c b/xen/common/timer.c
> > > index 0fddfa7487..bf7792dcb3 100644
> > > --- a/xen/common/timer.c
> > > +++ b/xen/common/timer.c
> > > @@ -291,7 +291,7 @@ static bool active_timer(const struct timer *timer)
> > >     void init_timer(
> > >       struct timer *timer,
> > > -    void        (*function)(void *),
> > > +    void        (*function)(void *data),
> > >       void         *data,
> > >       unsigned int  cpu)
> > >   {
> > > @@ -441,7 +441,7 @@ void kill_timer(struct timer *timer)
> > >     static void execute_timer(struct timers *ts, struct timer *t)
> > >   {
> > > -    void (*fn)(void *) = t->function;
> > > +    void (*fn)(void *data) = t->function;
> > >       void *data = t->data;
> > >         t->status = TIMER_STATUS_inactive;
> > > diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
> > > index 135f33f606..390f7b6082 100644
> > > --- a/xen/include/xen/rangeset.h
> > > +++ b/xen/include/xen/rangeset.h
> > > @@ -68,7 +68,7 @@ bool_t __must_check rangeset_overlaps_range(
> > >       struct rangeset *r, unsigned long s, unsigned long e);
> > >   int rangeset_report_ranges(
> > >       struct rangeset *r, unsigned long s, unsigned long e,
> > > -    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
> > > +    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt);
> > 
> > Also here some of the functions use "arg" instead of ctxt
> > 
> > 
> > >   /*
> > >    * Note that the consume function can return an error value apart from
> > > @@ -77,7 +77,7 @@ int rangeset_report_ranges(
> > >    */
> > >   int rangeset_consume_ranges(struct rangeset *r,
> > >                               int (*cb)(unsigned long s, unsigned long e,
> > > -                                      void *, unsigned long *c),
> > > +                                      void *ctxt, unsigned long *c),
> > >                               void *ctxt);
> > 
> > Also here some of the functions use "dom" like irq_remove_cb.
> > 
> > 
> > But I actually like the patch as is, so if that's OK from a MISRA point
> > of view then I would give my reviewed-by.
> 
> Yes, this is OK for MISRA.


Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-20 16:00       ` Jan Beulich
@ 2023-11-21  0:04         ` Stefano Stabellini
  2023-11-21  7:33           ` Jan Beulich
  0 siblings, 1 reply; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-21  0:04 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Federico Serafini, consulting, Andrew Cooper, George Dunlap,
	Julien Grall, Stefano Stabellini, Wei Liu, xen-devel

On Mon, 20 Nov 2023, Jan Beulich wrote:
> On 20.11.2023 14:13, Federico Serafini wrote:
> > On 20/11/23 10:02, Jan Beulich wrote:
> >> On 17.11.2023 09:40, Federico Serafini wrote:
> >>> --- a/xen/include/xen/sort.h
> >>> +++ b/xen/include/xen/sort.h
> >>> @@ -23,8 +23,8 @@
> >>>   extern gnu_inline
> >>>   #endif
> >>>   void sort(void *base, size_t num, size_t size,
> >>> -          int (*cmp)(const void *, const void *),
> >>> -          void (*swap)(void *, void *, size_t))
> >>> +          int (*cmp)(const void *key, const void *elem),
> >>
> >> Why "key" and "elem" here, but ...
> >>
> >>> +          void (*swap)(void *a, void *b, size_t size))
> >>
> >> ... "a" and "b" here? The first example of users of sort() that I'm
> >> looking at right now (x86/extable.c) is consistent in its naming.
> >>
> > 
> > On the Arm side there are {cmp,swap}_memory_node() and
> > {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
> > and "_a"/"_b" for the swap.
> 
> So - re-raising a question Stefano did raise - is Misra concerned about
> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
> see no reason to go with misleading names here.

Federico confirmed that the answer is "no".

I think we can use "key" and "elem" in this patch as they are more
informative than "a" and "b"


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-21  0:04         ` Stefano Stabellini
@ 2023-11-21  7:33           ` Jan Beulich
  2023-11-22  1:19             ` Stefano Stabellini
  0 siblings, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2023-11-21  7:33 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Federico Serafini, consulting, Andrew Cooper, George Dunlap,
	Julien Grall, Wei Liu, xen-devel

On 21.11.2023 01:04, Stefano Stabellini wrote:
> On Mon, 20 Nov 2023, Jan Beulich wrote:
>> On 20.11.2023 14:13, Federico Serafini wrote:
>>> On 20/11/23 10:02, Jan Beulich wrote:
>>>> On 17.11.2023 09:40, Federico Serafini wrote:
>>>>> --- a/xen/include/xen/sort.h
>>>>> +++ b/xen/include/xen/sort.h
>>>>> @@ -23,8 +23,8 @@
>>>>>   extern gnu_inline
>>>>>   #endif
>>>>>   void sort(void *base, size_t num, size_t size,
>>>>> -          int (*cmp)(const void *, const void *),
>>>>> -          void (*swap)(void *, void *, size_t))
>>>>> +          int (*cmp)(const void *key, const void *elem),
>>>>
>>>> Why "key" and "elem" here, but ...
>>>>
>>>>> +          void (*swap)(void *a, void *b, size_t size))
>>>>
>>>> ... "a" and "b" here? The first example of users of sort() that I'm
>>>> looking at right now (x86/extable.c) is consistent in its naming.
>>>>
>>>
>>> On the Arm side there are {cmp,swap}_memory_node() and
>>> {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
>>> and "_a"/"_b" for the swap.
>>
>> So - re-raising a question Stefano did raise - is Misra concerned about
>> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
>> see no reason to go with misleading names here.
> 
> Federico confirmed that the answer is "no".
> 
> I think we can use "key" and "elem" in this patch as they are more
> informative than "a" and "b"

Except that "key" and "elem" are (imo) inapplicable to sort() callbacks
(and inconsistent with the naming in the 2nd callback here); they _may_
be applicable in bsearch() ones. Note also how in the C99 spec these
parameters of callback functions don't have names either.

Jan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-21  7:33           ` Jan Beulich
@ 2023-11-22  1:19             ` Stefano Stabellini
  2023-11-22  8:01               ` Jan Beulich
  0 siblings, 1 reply; 22+ messages in thread
From: Stefano Stabellini @ 2023-11-22  1:19 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Federico Serafini, consulting, Andrew Cooper,
	George Dunlap, Julien Grall, Wei Liu, xen-devel

On Tue, 21 Nov 2023, Jan Beulich wrote:
> On 21.11.2023 01:04, Stefano Stabellini wrote:
> > On Mon, 20 Nov 2023, Jan Beulich wrote:
> >> On 20.11.2023 14:13, Federico Serafini wrote:
> >>> On 20/11/23 10:02, Jan Beulich wrote:
> >>>> On 17.11.2023 09:40, Federico Serafini wrote:
> >>>>> --- a/xen/include/xen/sort.h
> >>>>> +++ b/xen/include/xen/sort.h
> >>>>> @@ -23,8 +23,8 @@
> >>>>>   extern gnu_inline
> >>>>>   #endif
> >>>>>   void sort(void *base, size_t num, size_t size,
> >>>>> -          int (*cmp)(const void *, const void *),
> >>>>> -          void (*swap)(void *, void *, size_t))
> >>>>> +          int (*cmp)(const void *key, const void *elem),
> >>>>
> >>>> Why "key" and "elem" here, but ...
> >>>>
> >>>>> +          void (*swap)(void *a, void *b, size_t size))
> >>>>
> >>>> ... "a" and "b" here? The first example of users of sort() that I'm
> >>>> looking at right now (x86/extable.c) is consistent in its naming.
> >>>>
> >>>
> >>> On the Arm side there are {cmp,swap}_memory_node() and
> >>> {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
> >>> and "_a"/"_b" for the swap.
> >>
> >> So - re-raising a question Stefano did raise - is Misra concerned about
> >> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
> >> see no reason to go with misleading names here.
> > 
> > Federico confirmed that the answer is "no".
> > 
> > I think we can use "key" and "elem" in this patch as they are more
> > informative than "a" and "b"
> 
> Except that "key" and "elem" are (imo) inapplicable to sort() callbacks
> (and inconsistent with the naming in the 2nd callback here); they _may_
> be applicable in bsearch() ones. Note also how in the C99 spec these
> parameters of callback functions don't have names either.

Yes, reading the example in extable.c I think you are right. Maybe it is
better to use "a" and "b" in both cmp and swap if you agree.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-22  1:19             ` Stefano Stabellini
@ 2023-11-22  8:01               ` Jan Beulich
  2023-11-22 10:05                 ` Federico Serafini
  0 siblings, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2023-11-22  8:01 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Federico Serafini, consulting, Andrew Cooper, George Dunlap,
	Julien Grall, Wei Liu, xen-devel

On 22.11.2023 02:19, Stefano Stabellini wrote:
> On Tue, 21 Nov 2023, Jan Beulich wrote:
>> On 21.11.2023 01:04, Stefano Stabellini wrote:
>>> On Mon, 20 Nov 2023, Jan Beulich wrote:
>>>> On 20.11.2023 14:13, Federico Serafini wrote:
>>>>> On 20/11/23 10:02, Jan Beulich wrote:
>>>>>> On 17.11.2023 09:40, Federico Serafini wrote:
>>>>>>> --- a/xen/include/xen/sort.h
>>>>>>> +++ b/xen/include/xen/sort.h
>>>>>>> @@ -23,8 +23,8 @@
>>>>>>>   extern gnu_inline
>>>>>>>   #endif
>>>>>>>   void sort(void *base, size_t num, size_t size,
>>>>>>> -          int (*cmp)(const void *, const void *),
>>>>>>> -          void (*swap)(void *, void *, size_t))
>>>>>>> +          int (*cmp)(const void *key, const void *elem),
>>>>>>
>>>>>> Why "key" and "elem" here, but ...
>>>>>>
>>>>>>> +          void (*swap)(void *a, void *b, size_t size))
>>>>>>
>>>>>> ... "a" and "b" here? The first example of users of sort() that I'm
>>>>>> looking at right now (x86/extable.c) is consistent in its naming.
>>>>>>
>>>>>
>>>>> On the Arm side there are {cmp,swap}_memory_node() and
>>>>> {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
>>>>> and "_a"/"_b" for the swap.
>>>>
>>>> So - re-raising a question Stefano did raise - is Misra concerned about
>>>> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
>>>> see no reason to go with misleading names here.
>>>
>>> Federico confirmed that the answer is "no".
>>>
>>> I think we can use "key" and "elem" in this patch as they are more
>>> informative than "a" and "b"
>>
>> Except that "key" and "elem" are (imo) inapplicable to sort() callbacks
>> (and inconsistent with the naming in the 2nd callback here); they _may_
>> be applicable in bsearch() ones. Note also how in the C99 spec these
>> parameters of callback functions don't have names either.
> 
> Yes, reading the example in extable.c I think you are right. Maybe it is
> better to use "a" and "b" in both cmp and swap if you agree.

Using a and b is (as it looks) in line with at least some uses we have, so
less code churn than going with some other, more descriptive names (like
left/right). So yes, I'm okay with using a/b.

Jan


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 3/5] xen/sort: address violations of MISRA C:2012 Rule 8.2
  2023-11-22  8:01               ` Jan Beulich
@ 2023-11-22 10:05                 ` Federico Serafini
  0 siblings, 0 replies; 22+ messages in thread
From: Federico Serafini @ 2023-11-22 10:05 UTC (permalink / raw)
  To: Jan Beulich, Stefano Stabellini
  Cc: consulting, Andrew Cooper, George Dunlap, Julien Grall, Wei Liu,
	xen-devel

On 22/11/23 09:01, Jan Beulich wrote:
> On 22.11.2023 02:19, Stefano Stabellini wrote:
>> On Tue, 21 Nov 2023, Jan Beulich wrote:
>>> On 21.11.2023 01:04, Stefano Stabellini wrote:
>>>> On Mon, 20 Nov 2023, Jan Beulich wrote:
>>>>> On 20.11.2023 14:13, Federico Serafini wrote:
>>>>>> On 20/11/23 10:02, Jan Beulich wrote:
>>>>>>> On 17.11.2023 09:40, Federico Serafini wrote:
>>>>>>>> --- a/xen/include/xen/sort.h
>>>>>>>> +++ b/xen/include/xen/sort.h
>>>>>>>> @@ -23,8 +23,8 @@
>>>>>>>>    extern gnu_inline
>>>>>>>>    #endif
>>>>>>>>    void sort(void *base, size_t num, size_t size,
>>>>>>>> -          int (*cmp)(const void *, const void *),
>>>>>>>> -          void (*swap)(void *, void *, size_t))
>>>>>>>> +          int (*cmp)(const void *key, const void *elem),
>>>>>>>
>>>>>>> Why "key" and "elem" here, but ...
>>>>>>>
>>>>>>>> +          void (*swap)(void *a, void *b, size_t size))
>>>>>>>
>>>>>>> ... "a" and "b" here? The first example of users of sort() that I'm
>>>>>>> looking at right now (x86/extable.c) is consistent in its naming.
>>>>>>>
>>>>>>
>>>>>> On the Arm side there are {cmp,swap}_memory_node() and
>>>>>> {cmp,swap}_mmio_handler(): "key"/"elem" are used for the comparison
>>>>>> and "_a"/"_b" for the swap.
>>>>>
>>>>> So - re-raising a question Stefano did raise - is Misra concerned about
>>>>> such discrepancies? If yes, _all_ instances need harmonizing. If not, I
>>>>> see no reason to go with misleading names here.
>>>>
>>>> Federico confirmed that the answer is "no".
>>>>
>>>> I think we can use "key" and "elem" in this patch as they are more
>>>> informative than "a" and "b"
>>>
>>> Except that "key" and "elem" are (imo) inapplicable to sort() callbacks
>>> (and inconsistent with the naming in the 2nd callback here); they _may_
>>> be applicable in bsearch() ones. Note also how in the C99 spec these
>>> parameters of callback functions don't have names either.
>>
>> Yes, reading the example in extable.c I think you are right. Maybe it is
>> better to use "a" and "b" in both cmp and swap if you agree.
> 
> Using a and b is (as it looks) in line with at least some uses we have, so
> less code churn than going with some other, more descriptive names (like
> left/right). So yes, I'm okay with using a/b.

I'll send a new version.

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [XEN PATCH 1/5] xen/common: address violations of MISRA C:2012 Rule 8.2
  2023-11-21  0:02       ` Stefano Stabellini
@ 2023-11-23  8:59         ` Jan Beulich
  0 siblings, 0 replies; 22+ messages in thread
From: Jan Beulich @ 2023-11-23  8:59 UTC (permalink / raw)
  To: Federico Serafini
  Cc: xen-devel, consulting, Andrew Cooper, George Dunlap, Julien Grall,
	Wei Liu, Stefano Stabellini

On 21.11.2023 01:02, Stefano Stabellini wrote:
> On Mon, 19 Nov 2023, Federico Serafini wrote:
>> On 18/11/23 03:59, Stefano Stabellini wrote:
>>> On Fri, 17 Nov 2023, Federico Serafini wrote:
>>>> diff --git a/xen/common/stop_machine.c b/xen/common/stop_machine.c
>>>> index 3adbe380de..398cfd507c 100644
>>>> --- a/xen/common/stop_machine.c
>>>> +++ b/xen/common/stop_machine.c
>>>> @@ -46,7 +46,7 @@ struct stopmachine_data {
>>>>         unsigned int fn_cpu;
>>>>       int fn_result;
>>>> -    int (*fn)(void *);
>>>> +    int (*fn)(void *data);
>>>>       void *fn_data;
>>>>   };
>>>
>>> At least one of the possible function used here calls the parameter
>>> "arg", see take_cpu_down. But I don't think it is a MISRA requirement to
>>> also harmonize those?
>>>
>>>
>>>> @@ -73,7 +73,7 @@ static void stopmachine_wait_state(void)
>>>>    * mandatory to be called only on an idle vcpu, as otherwise active core
>>>>    * scheduling might hang.
>>>>    */
>>>> -int stop_machine_run(int (*fn)(void *), void *data, unsigned int cpu)
>>>> +int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>>>>   {
>>>>       unsigned int i, nr_cpus;
>>>>       unsigned int this = smp_processor_id();
>>>> diff --git a/xen/common/tasklet.c b/xen/common/tasklet.c
>>>> index 3ad67b5c24..3649798e6b 100644
>>>> --- a/xen/common/tasklet.c
>>>> +++ b/xen/common/tasklet.c
>>>> @@ -199,7 +199,7 @@ static void migrate_tasklets_from_cpu(unsigned int
>>>> cpu, struct list_head *list)
>>>>       spin_unlock_irqrestore(&tasklet_lock, flags);
>>>>   }
>>>>   -void tasklet_init(struct tasklet *t, void (*func)(void *), void *data)
>>>> +void tasklet_init(struct tasklet *t, void (*func)(void *data), void
>>>> *data)
>>>>   {
>>>>       memset(t, 0, sizeof(*t));
>>>>       INIT_LIST_HEAD(&t->list);
>>>> @@ -208,7 +208,8 @@ void tasklet_init(struct tasklet *t, void (*func)(void
>>>> *), void *data)
>>>>       t->data = data;
>>>>   }
>>>>   -void softirq_tasklet_init(struct tasklet *t, void (*func)(void *), void
>>>> *data)
>>>> +void softirq_tasklet_init(struct tasklet *t,
>>>> +                          void (*func)(void *data), void *data)
>>>>   {
>>>>       tasklet_init(t, func, data);
>>>>       t->is_softirq = 1;
>>>> diff --git a/xen/common/timer.c b/xen/common/timer.c
>>>> index 0fddfa7487..bf7792dcb3 100644
>>>> --- a/xen/common/timer.c
>>>> +++ b/xen/common/timer.c
>>>> @@ -291,7 +291,7 @@ static bool active_timer(const struct timer *timer)
>>>>     void init_timer(
>>>>       struct timer *timer,
>>>> -    void        (*function)(void *),
>>>> +    void        (*function)(void *data),
>>>>       void         *data,
>>>>       unsigned int  cpu)
>>>>   {
>>>> @@ -441,7 +441,7 @@ void kill_timer(struct timer *timer)
>>>>     static void execute_timer(struct timers *ts, struct timer *t)
>>>>   {
>>>> -    void (*fn)(void *) = t->function;
>>>> +    void (*fn)(void *data) = t->function;
>>>>       void *data = t->data;
>>>>         t->status = TIMER_STATUS_inactive;
>>>> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
>>>> index 135f33f606..390f7b6082 100644
>>>> --- a/xen/include/xen/rangeset.h
>>>> +++ b/xen/include/xen/rangeset.h
>>>> @@ -68,7 +68,7 @@ bool_t __must_check rangeset_overlaps_range(
>>>>       struct rangeset *r, unsigned long s, unsigned long e);
>>>>   int rangeset_report_ranges(
>>>>       struct rangeset *r, unsigned long s, unsigned long e,
>>>> -    int (*cb)(unsigned long s, unsigned long e, void *), void *ctxt);
>>>> +    int (*cb)(unsigned long s, unsigned long e, void *data), void *ctxt);
>>>
>>> Also here some of the functions use "arg" instead of ctxt
>>>
>>>
>>>>   /*
>>>>    * Note that the consume function can return an error value apart from
>>>> @@ -77,7 +77,7 @@ int rangeset_report_ranges(
>>>>    */
>>>>   int rangeset_consume_ranges(struct rangeset *r,
>>>>                               int (*cb)(unsigned long s, unsigned long e,
>>>> -                                      void *, unsigned long *c),
>>>> +                                      void *ctxt, unsigned long *c),
>>>>                               void *ctxt);
>>>
>>> Also here some of the functions use "dom" like irq_remove_cb.
>>>
>>>
>>> But I actually like the patch as is, so if that's OK from a MISRA point
>>> of view then I would give my reviewed-by.
>>
>> Yes, this is OK for MISRA.
> 
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

To cover EFI:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2023-11-23  8:59 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-17  8:40 [XEN PATCH 0/5] xen: address some violations of MISRA C:2012 Rule 8.2 Federico Serafini
2023-11-17  8:40 ` [XEN PATCH 1/5] xen/common: address " Federico Serafini
2023-11-18  2:59   ` Stefano Stabellini
2023-11-20 13:55     ` Federico Serafini
2023-11-21  0:02       ` Stefano Stabellini
2023-11-23  8:59         ` Jan Beulich
2023-11-17  8:40 ` [XEN PATCH 2/5] xen/serial: " Federico Serafini
2023-11-18  3:02   ` Stefano Stabellini
2023-11-17  8:40 ` [XEN PATCH 3/5] xen/sort: " Federico Serafini
2023-11-18  3:05   ` Stefano Stabellini
2023-11-20  9:02   ` Jan Beulich
2023-11-20 13:13     ` Federico Serafini
2023-11-20 16:00       ` Jan Beulich
2023-11-21  0:04         ` Stefano Stabellini
2023-11-21  7:33           ` Jan Beulich
2023-11-22  1:19             ` Stefano Stabellini
2023-11-22  8:01               ` Jan Beulich
2023-11-22 10:05                 ` Federico Serafini
2023-11-17  8:40 ` [XEN PATCH 4/5] xen/vmap: " Federico Serafini
2023-11-18  3:06   ` Stefano Stabellini
2023-11-17  8:40 ` [XEN PATCH 5/5] xen/xalloc: " Federico Serafini
2023-11-18  3:06   ` Stefano Stabellini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.