On 2023-11-22 17:46, Andrew Cooper wrote:
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 ?
I see that Simone already gave one; that should suffice.
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
That's fair. I also agree that an exception for this use of inline can
be made.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
