Re: Functions _spin_lock_cb() and handle_ro_raz()

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 14/06/23 16:03, Jan Beulich wrote:
> On 14.06.2023 15:08, Federico Serafini wrote:
> > Hello everyone,
> >
> > 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?
> Since this function was mentioned elsewhere already, I'm afraid I
> have to be a little blunt and ask back: Did you check the history
> of the function. Yes, it is intentional to be that way, for the
> function to be inlined into _spin_lock(), and for it to also be
> available for external callers (we have just one right now, but
> that could change).
>
> > What about solving the violation by moving the function definition in
> > spinlock.h and declaring it as static inline?
> Did you try whether that would work at least purely mechanically?
> I'm afraid you'll find that it doesn't, because of LOCK_PROFILE_*
> being unavailable then. Yet we also don't want to expose all that
> in the header.
>
> In the earlier context I did suggest already to make the function
> an always-inline one in spinlock.c, under a slightly altered name,
> and then have _spin_lock_cb() be a trivial wrapper just like
> _spin_lock() is. I guess best is going to be if I make and post a
> patch ...
>
> Jan
Thank you for the information.

Federico