1. Patchew
  2. Xen
  3. [XEN PATCH 0/3] Move Xen ECLAIR configuration to analyze.yaml
  4. View patch

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

Nicola Vetrini posted 3 patches 8 months, 2 weeks ago
There is a newer version of this series
[XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2
Posted by Nicola Vetrini 8 months, 2 weeks ago 
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.vetrini@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(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index f368e0fdd5a5..0300d2d2e454 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, struct list_head *elem)
 }
 
 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),
                       struct rt_unit *svc, struct list_head *elem,
                       struct list_head *queue)
 {
-- 
2.43.0
Re: [XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2
Posted by Stefano Stabellini 8 months, 2 weeks ago 
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.vetrini@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(-)
> 
> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
> index f368e0fdd5a5..0300d2d2e454 100644
> --- a/xen/common/sched/rt.c
> +++ b/xen/common/sched/rt.c
> @@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, struct list_head *elem)
>  }
>  
>  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),

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

Other than that:

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

The small change can be done on commit.


>                        struct rt_unit *svc, struct list_head *elem,
>                        struct list_head *queue)
>  {
> -- 
> 2.43.0
>
Re: [XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2
Posted by Jan Beulich 8 months, 2 weeks ago 
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.vetrini@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.

>> --- a/xen/common/sched/rt.c
>> +++ b/xen/common/sched/rt.c
>> @@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, struct list_head *elem)
>>  }
>>  
>>  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),
> 
> 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
Re: [XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2
Posted by Nicola Vetrini 8 months, 2 weeks ago 
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.vetrini@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
>>> @@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, 
>>> struct list_head *elem)
>>>  }
>>> 
>>>  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),
>> 
>> 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.

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: [XEN PATCH 2/3] xen/sched: address violation of MISRA C Rule 8.2
Posted by Jürgen Groß 8 months, 2 weeks ago 
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.vetrini@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
>>>> @@ -500,7 +500,7 @@ deadline_queue_remove(struct list_head *queue, struct 
>>>> list_head *elem)
>>>>  }
>>>>
>>>>  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),
>>>
>>> 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 <jgross@suse.com>


Juergen

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.