On 22/11/2023 4:39 pm, Nicola Vetrini wrote: > On 2023-11-22 15:27, Andrew Cooper wrote: >> The differences between inline, __inline and __inline__ keywords are a >> vestigial remnant of older C standards, and in Xen we use inline almost >> exclusively. >> >> Replace __inline and __inline__ with regular inline, and remove their >> exceptions from the MISRA configuration. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> --- >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Roger Pau Monné <roger....@citrix.com> >> CC: Wei Liu <w...@xen.org> >> CC: Stefano Stabellini <sstabell...@kernel.org> >> CC: Roberto Bagnara <roberto.bagn...@bugseng.com> >> CC: Nicola Vetrini <nicola.vetr...@bugseng.com> >> CC: Simone Ballarin <simone.balla...@bugseng.com> >> >> I'm entirely guessing at the Eclair configuration. >> --- > > The configuration changes are ok. One observation below.
Thanks. Can I take that as an Ack/Reviewed-by ? >> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h >> index 04b8bc18df0e..16d554f2a593 100644 >> --- a/xen/include/xen/compiler.h >> +++ b/xen/include/xen/compiler.h >> @@ -83,7 +82,7 @@ >> * inline functions not expanded inline get placed in .init.text. >> */ >> #include <xen/init.h> >> -#define __inline__ __inline__ __init >> +#define inline inline __init > > The violation of Rule 20.4 (A macro shall not be defined with the same > name as a keyword) is still present due to this macro. I was expecting this to come up. There's a comment half out of context above, but to expand on it, we have a feature in the build system where if you say obj-y += foo.init.o then it gets compiled as normal and then all symbols checked for being in the relevant .init sections. It's a safeguard around init-only code ending up in the runtime image (which is good for other goals of safety). This particular define is necessary to cause out-of-lined static inlines to end up in the right section, without having to invent a new __inline_or_init macro and rewriting half the header files in the project. I think it's going to need a local deviation. It's deliberate, and all we're doing is using the inline keyword to hook in an extra __section() attribute. ~Andrew