Re: [PATCH 3/3] xen/MISRA: Remove nonstandard inline keywords

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Roberto Bagnara" <roberto.bagnara@bugseng.com>,
	"Simone Ballarin" <simone.ballarin@bugseng.com>
Subject: Re: [PATCH 3/3] xen/MISRA: Remove nonstandard inline keywords
Date: Wed, 22 Nov 2023 16:46:19 +0000	[thread overview]
Message-ID: <adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com> (raw)
In-Reply-To: <e5476808dbef67bea7ce3902d4d8b3c1@bugseng.com>

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.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Wei Liu <wl@xen.org>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Roberto Bagnara <roberto.bagnara@bugseng.com>
>> CC: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> CC: Simone Ballarin <simone.ballarin@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