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

Reply via email to