All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Julien Grall <julien@xen.org>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	michal.orzel@amd.com, xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com, consulting@bugseng.com,
	jbeulich@suse.com, andrew.cooper3@citrix.com,
	roger.pau@citrix.com, George Dunlap <george.dunlap@citrix.com>,
	Wei Liu <wl@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [XEN PATCH][for-4.19] xen: replace occurrences of SAF-1-safe with asmlinkage attribute
Date: Tue, 07 Nov 2023 09:36:15 +0100	[thread overview]
Message-ID: <bb40675e3372abf264dcd63d0d64d476@bugseng.com> (raw)
In-Reply-To: <ef60f721-f784-4595-8866-e1c57da7e48f@xen.org>

On 2023-11-06 23:57, Julien Grall wrote:
> Hi Nicola,
> 
> On 03/11/2023 18:05, Nicola Vetrini wrote:
>> The comment-based justifications for MISRA C:2012 Rule 8.4 are 
>> replaced
>> by the asmlinkage pseudo-attribute, for the sake of uniformity.
>> The deviation with a comment based on the SAF framework is also
>> mentioned as a last resort.
> 
> I don't see any reason to keep SAF-1 after this patch. So can this be 
> removed?
> 

In documenting-violations.rst it's stated:
"Entries in the database shall never be removed, even if they are not 
used
anymore in the code (if a patch is removing or modifying the faulty 
line).
This is to make sure that numbers are not reused which could lead to 
conflicts
with old branches or misleading justifications."

that's why I kept SAF-1 in the safe.json file and added the remark about 
it
being a last resort. I am ok with that remark becoming not to use SAF-1 
in new code
at all (I probably didn't go back to check your reply when writing the 
patch).

>> 
>> Add missing 'xen/compiler.h' #include-s where needed.
>> 
>> The text in docs/misra/deviations.rst is modified to reflect this 
>> change.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> ---
>>   docs/misra/deviations.rst   |  6 +++---
>>   xen/arch/arm/cpuerrata.c    |  7 +++----
>>   xen/arch/arm/setup.c        |  5 ++---
>>   xen/arch/arm/smpboot.c      |  3 +--
>>   xen/arch/arm/traps.c        | 21 +++++++--------------
>>   xen/arch/x86/boot/cmdline.c |  5 +++--
>>   xen/arch/x86/boot/reloc.c   |  7 ++++---
>>   xen/arch/x86/extable.c      |  3 +--
>>   xen/arch/x86/setup.c        |  3 +--
>>   xen/arch/x86/traps.c        | 27 +++++++++------------------
>>   xen/common/efi/boot.c       |  5 ++---
>>   11 files changed, 36 insertions(+), 56 deletions(-)
>> 
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index d468da2f5ce9..ed5d36c08647 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -134,9 +134,9 @@ Deviations related to MISRA C:2012 Rules:
>>        - Tagged as `safe` for ECLAIR.
>>        * - R8.4
>> -     - Functions and variables used only by asm modules are either 
>> marked with
>> -       the `asmlinkage` macro or with a SAF-1-safe textual deviation
>> -       (see safe.json).
> 
> I thought we agreed to a different wording [1]. So is this really based 
> on last version?
> 
>> +     - Functions and variables used only to interface with asm 
>> modules should
>> +       be marked with the `asmlinkage` macro. If that's not possible, 
>> consider
>> +       using the SAF-1-safe textual deviation (see safe.json).
> 
> See above. Actually, I am a bit surprised that SAF-1 is still mentioned 
> given that I have now requested multiple that it should be removed and 
> I haven't yet seen a reason to keep it.
> 
> Cheers,
> 
> [1] 
> https://lore.kernel.org/all/b914ac93-2499-4bfd-a60a-51a9f1c170ec@xen.org/

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


  reply	other threads:[~2023-11-07  8:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-03 18:05 [XEN PATCH][for-4.19] xen: replace occurrences of SAF-1-safe with asmlinkage attribute Nicola Vetrini
2023-11-06 22:57 ` Julien Grall
2023-11-07  8:36   ` Nicola Vetrini [this message]
2023-11-07  9:49     ` Julien Grall
2023-11-07 10:22       ` Nicola Vetrini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb40675e3372abf264dcd63d0d64d476@bugseng.com \
    --to=nicola.vetrini@bugseng.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=consulting@bugseng.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.