Re: Functions _spin_lock_cb() and handle_ro_raz()

[Julien Grall <julien@xxxxxxx>]

(+ Bertrand and Stefano)

On 14/06/2023 14:08, Federico Serafini wrote:
> Hello everyone,
Hi Federico,

Let me start with a tip to help reaching the maintainers and getting a 
more timely answer. Xen-devel has a large volume of e-mails (still less 
than Linux :)). So some of us will have filter to try to classify the 
e-mails received.
Commonly, all the e-mails where the person is in the CC/To list will go 
to the inbox. All the others will go a separate directory that may or 
may not be watched. Personally, I tend to glance in that directory, but 
I would not read all of them.
So I would highly recommend to CC the maintainers/reviewers of the 
specific component. You can find them in MAINTAINERS at the root of the 
Xen repository. We also have script like scripts/get_maintainers.pl that 
can help you to find who to CC.
If you pass '-f <file>', it will output the maintainers of that file. 
You can also use the script with patch to find all the maintainers to CC.
Now back to the subject of the e-mail.

> I am working on the violations of MISRA C:2012 Rule 8.10,
> whose headline says:
> "An inline function shall be declared with the static storage class".
>
> For both ARM64 and X86_64 builds,
> function _spin_lock_cb() defined in spinlock.c violates the rule.
> Such function is declared in spinlock.h without
> the inline function specifier: are there any reasons to do this?
> What about solving the violation by moving the function definition in
> spinlock.h and declaring it as static inline?
Jan answered it and sent a patch. So I will skip the reply for this one.

> The same happens also for the function handle_ro_raz() in the ARM64
> build, declared in traps.h and defined in traps.c.
I looked at the history and it is not clear to me why the 'inline' was 
added at first. That said, I don't see any value to ask the compiler to 
inline (which it would be free to ignore) the function.
So I would suggest to send a patch to remove the 'inline'.

Best regards,

--
Julien Grall