Re: Functions _spin_lock_cb() and handle_ro_raz()

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 14/06/23 19:59, Julien Grall wrote:
> (+ 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,
Thank you Julien, very helpful.