| Message ID | d2b3ae062756a28a040a9553a4f0e621cfdeb5e0.1709885163.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [XEN] xen/compiler: deviate the inline macro for MISRA C Rule 20.4 | expand |
On Fri, 8 Mar 2024, Nicola Vetrini wrote: > Rule 20.4 states: "A macro shall not be defined with the same name > as a keyword". > > Defining this macro with the same name as the inline keyword > allows for additionally checking that out-of-lined static inline > functions end up in the correct section while minimizing churn and > has a positive impact on the overall safety. See [1] for additional > context on the motivation of this deviation. > > No functional change. > > [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On 08.03.2024 09:10, Nicola Vetrini wrote: > Rule 20.4 states: "A macro shall not be defined with the same name > as a keyword". > > Defining this macro with the same name as the inline keyword > allows for additionally checking that out-of-lined static inline > functions end up in the correct section while minimizing churn and > has a positive impact on the overall safety. See [1] for additional > context on the motivation of this deviation. > > No functional change. > > [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > --- > docs/misra/safe.json | 8 ++++++++ > xen/include/xen/compiler.h | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/docs/misra/safe.json b/docs/misra/safe.json > index 952324f85cf9..a2bbacddf06a 100644 > --- a/docs/misra/safe.json > +++ b/docs/misra/safe.json > @@ -28,6 +28,14 @@ > }, > { > "id": "SAF-3-safe", > + "analyser": { > + "eclair": "MC3R1.R20.4" > + }, > + "name": "MC3R1.R20.4: allow the augmentation of the inline keyword in some build configurations", > + "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections." > + }, With this wording the ID isn't going to be re-usable anywhere else. Even if the exact same reasoning would apply. > + { > + "id": "SAF-4-safe", > "analyser": {}, > "name": "Sentinel", > "text": "Next ID to be used" > diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h > index 16d554f2a593..e3d9f9fb8e4b 100644 > --- a/xen/include/xen/compiler.h > +++ b/xen/include/xen/compiler.h > @@ -82,6 +82,7 @@ > * inline functions not expanded inline get placed in .init.text. > */ > #include <xen/init.h> > +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform checks */ > #define inline inline __init > #endif I don't think the definition is "to perform checks"; it's rather to make sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override "inline" for section contents checks to pass when the compiler chooses not to inline a particular function' perhaps? Albeit that's getting long-ish, I fear. Jan
On 2024-03-11 08:32, Jan Beulich wrote: > On 08.03.2024 09:10, Nicola Vetrini wrote: >> Rule 20.4 states: "A macro shall not be defined with the same name >> as a keyword". >> >> Defining this macro with the same name as the inline keyword >> allows for additionally checking that out-of-lined static inline >> functions end up in the correct section while minimizing churn and >> has a positive impact on the overall safety. See [1] for additional >> context on the motivation of this deviation. >> >> No functional change. >> >> [1] >> https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ >> >> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> >> --- >> docs/misra/safe.json | 8 ++++++++ >> xen/include/xen/compiler.h | 1 + >> 2 files changed, 9 insertions(+) >> >> diff --git a/docs/misra/safe.json b/docs/misra/safe.json >> index 952324f85cf9..a2bbacddf06a 100644 >> --- a/docs/misra/safe.json >> +++ b/docs/misra/safe.json >> @@ -28,6 +28,14 @@ >> }, >> { >> "id": "SAF-3-safe", >> + "analyser": { >> + "eclair": "MC3R1.R20.4" >> + }, >> + "name": "MC3R1.R20.4: allow the augmentation of the >> inline keyword in some build configurations", >> + "text": "The definition of this macro named inline allows >> further checking in some build configurations that certain symbols end >> up in the right sections." >> + }, > > With this wording the ID isn't going to be re-usable anywhere else. > Even > if the exact same reasoning would apply. > What about "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases" and "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases. and then.. >> + { >> + "id": "SAF-4-safe", >> "analyser": {}, >> "name": "Sentinel", >> "text": "Next ID to be used" >> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h >> index 16d554f2a593..e3d9f9fb8e4b 100644 >> --- a/xen/include/xen/compiler.h >> +++ b/xen/include/xen/compiler.h >> @@ -82,6 +82,7 @@ >> * inline functions not expanded inline get placed in .init.text. >> */ >> #include <xen/init.h> >> +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform >> checks */ >> #define inline inline __init >> #endif > > I don't think the definition is "to perform checks"; it's rather to > make > sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override > "inline" for section contents checks to pass when the compiler chooses > not to inline a particular function' perhaps? Albeit that's getting > long-ish, I fear. put this message in deviations.rst > > Jan is this proposal more appealing?
On 11.03.2024 16:48, Nicola Vetrini wrote: > On 2024-03-11 08:32, Jan Beulich wrote: >> On 08.03.2024 09:10, Nicola Vetrini wrote: >>> --- a/docs/misra/safe.json >>> +++ b/docs/misra/safe.json >>> @@ -28,6 +28,14 @@ >>> }, >>> { >>> "id": "SAF-3-safe", >>> + "analyser": { >>> + "eclair": "MC3R1.R20.4" >>> + }, >>> + "name": "MC3R1.R20.4: allow the augmentation of the >>> inline keyword in some build configurations", >>> + "text": "The definition of this macro named inline allows >>> further checking in some build configurations that certain symbols end >>> up in the right sections." >>> + }, >> >> With this wording the ID isn't going to be re-usable anywhere else. >> Even >> if the exact same reasoning would apply. >> > > What about > > "name": "MC3R1.R20.4: allow the definition of a macro with the same name > as a keyword in some special cases" > > and > > "text": "The definition of a macro with the same name as a keyword can > be useful in certain configurations to improve the guarantees that can > be provided by Xen. See docs/misra/deviations.rst for a precise > rationale for all such cases. > > and then.. > >>> + { >>> + "id": "SAF-4-safe", >>> "analyser": {}, >>> "name": "Sentinel", >>> "text": "Next ID to be used" >>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h >>> index 16d554f2a593..e3d9f9fb8e4b 100644 >>> --- a/xen/include/xen/compiler.h >>> +++ b/xen/include/xen/compiler.h >>> @@ -82,6 +82,7 @@ >>> * inline functions not expanded inline get placed in .init.text. >>> */ >>> #include <xen/init.h> >>> +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform >>> checks */ >>> #define inline inline __init >>> #endif >> >> I don't think the definition is "to perform checks"; it's rather to >> make >> sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override >> "inline" for section contents checks to pass when the compiler chooses >> not to inline a particular function' perhaps? Albeit that's getting >> long-ish, I fear. > > put this message in deviations.rst > > is this proposal more appealing? I think so, yes. Jan
diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 952324f85cf9..a2bbacddf06a 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -28,6 +28,14 @@ }, { "id": "SAF-3-safe", + "analyser": { + "eclair": "MC3R1.R20.4" + }, + "name": "MC3R1.R20.4: allow the augmentation of the inline keyword in some build configurations", + "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections." + }, + { + "id": "SAF-4-safe", "analyser": {}, "name": "Sentinel", "text": "Next ID to be used" diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h index 16d554f2a593..e3d9f9fb8e4b 100644 --- a/xen/include/xen/compiler.h +++ b/xen/include/xen/compiler.h @@ -82,6 +82,7 @@ * inline functions not expanded inline get placed in .init.text. */ #include <xen/init.h> +/* SAF-3-safe MISRA C Rule 20.4: define the inline macro to perform checks */ #define inline inline __init #endif
Rule 20.4 states: "A macro shall not be defined with the same name as a keyword". Defining this macro with the same name as the inline keyword allows for additionally checking that out-of-lined static inline functions end up in the correct section while minimizing churn and has a positive impact on the overall safety. See [1] for additional context on the motivation of this deviation. No functional change. [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/ Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> --- docs/misra/safe.json | 8 ++++++++ xen/include/xen/compiler.h | 1 + 2 files changed, 9 insertions(+)