Re: [XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2

[Jürgen Groß]

On 17.02.25 09:31, Nicola Vetrini wrote:

On 2025-02-17 08:54, Jan Beulich wrote:

On 15.02.2025 00:04, Stefano Stabellini wrote:

On Fri, 14 Feb 2025, Nicola Vetrini wrote:

Rule 8.2 states: "Function types shall be in prototype form with
named parameters".

The parameter name is missing from the function pointer type
that constitutes the first parameter.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetr...@bugseng.com>
---
This small fix is needed in order to keep the rule clean in the
follow-up patch that changes the Xen configuration under static
analysis.

I wasn't really certain about the right name to give to the parameter,
so if there are better options I'd be happy to accept them.
---
 xen/common/sched/rt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is a specific scheduler you touch, which I think wants expressing
somehow (e.g. via an adjusted prefix) in the patch subject.

Ok. I think it should be "xen/rt" then.

--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c

 }

 static inline bool
-deadline_queue_insert(struct rt_unit * (*qelem)(struct list_head *),
+deadline_queue_insert(struct rt_unit * (*qelem)(struct list_head *q_iter),

@@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, struct list_head *elem)

I think it should be "elem" instead of "q_iter"

Why would it matter what the name is? There's no separate decl to stay in
sync with. (That said, I'd be happy with "elem"; it'll be a matter of the
maintainers to judge.)

Jan

I'd be ok with that too.

I think naming it "elem" is the better choice, as both functions used for
the qelem() parameter name their parameter "elem" already.

With that change:

Reviewed-by: Juergen Gross <jgr...@suse.com>


Juergen

OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature