[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-4.19 v5] xen: Add deviations for MISRA C:2012 Rule 7.1


  • To: Julien Grall <julien@xxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Tue, 31 Oct 2023 15:32:04 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dZzbHOT2qCzMwKZUwrYP3dtWMS6I52qgRrM4GzH4grA=; b=lR6EXqplKhu7sB2A5Tjk3BsDcaU3iYt/hzCYv+OOHNUlSayUMNjEG2/fEJS+O32ymXCf+/tjGnyuGMgtqE9OUErWwFlxFyurykXRa3iQ7SzJbKEab/s9bI8UiTFfrSCQYPvU8Xb13GOfz3nDEmParbioa0BTgHWfqbXEQF2nGpf+I66JS7yTqAYX/9PaK5s2eJ5GYo33ytGR3oJy7hSeGdDm6IhbGbbNzSuLGXXquL7K+Cs4QWWdY6Bj1hppuO83zwQogeGhjRujsHNvpAbTjjgeEU3WGlUMQYg3+JlCfenxsD6RSAYcGMTzNfEtEj+Ehft6A4u3NiPR1dwmArXQLA==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dZzbHOT2qCzMwKZUwrYP3dtWMS6I52qgRrM4GzH4grA=; b=bBfqqFEs5eVJdNH78OZ4uNwcAjXYx/M90udsw8Bspzx98S3DWSSaXPtybeyU/tV+SsQUU3auUAuTmi4pnds4n3xBPFsoBDd7O7tbiyBJAHwLEv6FK2etj2UrRV2ze99o+0p73+QXReEx3HuyFfdEhYDQseqMpFajfZM04SoyXL2/WkQQCXTbw095PhOJ3kfStQj6Pdvl/4fAxv0ad1ojhfmx7sPR15VzeZT7peHyUlH+J05qvKb/oYrGbnsiiVPJhDZzRU1HFOxLTV6VcIfI/VOQS3vWCtvgNJuqpsCi8c+Z8W/86TiJ4ObsO+zCZCTxIssJCLQDIw7idW+MgwrGkA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=MdmZTs8AQcPK43aBmBOP8ELjMC0e+TbK6s90qrFsUX0DQSAbW5EM8nrXB7nQf7bDgSP0uBk+omyIZLI2PKEZ8E8njxn781IUOV+LJD2N8ercOIMpdwujVIUfgOY4TwlSPFfClWp2AJpHCDmwPpERca5GvkYPYObodMid7a0jDnK9WA2sCiL+VJbpSM/DldDBcN625+dgZu8xakn9UKy+DI7m1VEuA+Q1exHenTBK8sgRDugL+sgkalplbqtOcRiOwGit6cilp/41PWhJSAbt3XyE9U0Vmn2NS7i6he5ZdzTd/szs0ene8lzHqZI08Z9p7SpLYzhKq6O96tFo6XkjRw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uwnv5f7g7jZsalwOzTaxS5udRS6CO8FDexsHTumVPPSaG/aXdQf+W4rs1i3EcKxw4hDFLWTPBNnV6dECIUnW5dj1qDYRx3rdmPDO9ujxp+0kNE+944GUJSD1B7mx+BIfCNFh497eWTd/Rtk27/scad9LooPO8xlZvI3EgFtKoWaLnzdeU4zneUzMcvXANjkRj22E26QrqyS82W7UfE2tvj3GBP40Nb0yYPgT+e4MVPYK4MxITaMoMPeyaAERzYHvhoQD5AlJMwcnrmVTz3Ckvk7+OE68g0CWKy7PVLjVVY2/lG1tgS8hLV0i/LJqU81kgY27J9y86qyIxvCR7hdciw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "michal.orzel@xxxxxxx" <michal.orzel@xxxxxxx>, "xenia.ragiadakou@xxxxxxx" <xenia.ragiadakou@xxxxxxx>, "ayan.kumar.halder@xxxxxxx" <ayan.kumar.halder@xxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>, "jbeulich@xxxxxxxx" <jbeulich@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 31 Oct 2023 15:32:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHaC/4b2xNoaiIkmUiyfHAuabY8yrBj8OgAgAAP5gCAAACVgIAABCCAgAABQIA=
  • Thread-topic: [XEN PATCH][for-4.19 v5] xen: Add deviations for MISRA C:2012 Rule 7.1


> On 31 Oct 2023, at 15:27, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi,
> 
> On 31/10/2023 15:12, Luca Fancellu wrote:
>>> On 31 Oct 2023, at 15:10, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> wrote:
>>> 
>>> On 2023-10-31 15:13, Luca Fancellu wrote:
>>>>> On 31 Oct 2023, at 13:27, Julien Grall <julien@xxxxxxx> wrote:
>>>>> Hi Stefano,
>>>>> On 30/10/2023 22:49, Stefano Stabellini wrote:
>>>>>> On Mon, 30 Oct 2023, Julien Grall wrote:
>>>>>>> Hi Nicola,
>>>>>>> On 27/10/2023 16:11, Nicola Vetrini wrote:
>>>>>>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>>>>>>> index 8511a189253b..8aaaa1473fb4 100644
>>>>>>>> --- a/docs/misra/deviations.rst
>>>>>>>> +++ b/docs/misra/deviations.rst
>>>>>>>> @@ -90,6 +90,13 @@ Deviations related to MISRA C:2012 Rules:
>>>>>>>>           - __emulate_2op and __emulate_2op_nobyte
>>>>>>>>           - read_debugreg and write_debugreg
>>>>>>>>  +   * - R7.1
>>>>>>>> +     - It is safe to use certain octal constants the way they are 
>>>>>>>> defined
>>>>>>>> +       in specifications, manuals, and algorithm descriptions. Such 
>>>>>>>> places
>>>>>>>> +       are marked safe with a /\* octal-ok \*/ in-code comment, or 
>>>>>>>> with a
>>>>>>>> SAF
>>>>>>>> +       comment (see safe.json).
>>>>>>> Reading this, it is unclear to me why we have two ways to deviate the 
>>>>>>> rule
>>>>>>> r7.1. And more importantely, how would the developper decide which one 
>>>>>>> to use?
>>>>>> I agree with you on this and we were discussing this topic just this
>>>>>> morning in the FUSA community call. I think we need a way to do this
>>>>>> with the SAF framework:
>>>>>> if (some code with violation) /* SAF-xx-safe */
>>>>>> This doesn't work today unfortunately. It can only be done this way:
>>>>>> /* SAF-xx-safe */
>>>>>> if (some code with violation)
>>>>>> Which is not always desirable. octal-ok is just an ad-hoc solution for
>>>>>> one specific violation but we need a generic way to do this. Luca is
>>>>>> investigating possible ways to support the previous format in SAF.
>>>>> Why can't we use octal-ok everywhere for now? My point here is to make 
>>>>> simple for the developper to know what to use.
>>>>>> I think we should take this patch for now and harmonize it once SAF is
>>>>>> improved.
>>>>> The description of the deviation needs some improvement. To give an 
>>>>> example, with the current wording, one could they can use octal-ok 
>>>>> everywhere. But above, you are implying that SAF-xx-safe should be
>>>>> preferred.
>>>>> I would still strongly prefer if we use octal-ok everywhere because this 
>>>>> is simple to remember. But if the other are happy to have both SAF-XX and 
>>>>> octal-ok, then the description needs to be completely unambiguous and the 
>>>>> patch should contain some explanation why we have two different ways to 
>>>>> deviate.
>>>> Would it be ok to have both, for example: /* SAF-XX-safe octal-ok */
>>>> So that the suppression engine do what it should (currently it doesn’t 
>>>> suppress the same line, but we could do something about it) and the 
>>>> developer
>>>> has a way to understand what is the violation here without going to the 
>>>> justification database.
>>> 
>>> I guess. It could overflow the 80-char limit in xen/arch/x86/hvm/svm/svm.h, 
>>> though.
>> Yeah, but we could rule out something in code_style to allow only this kind 
>> of trailing comments to exceed the 80 chars
> 
> In the past I expressed concerned with this kind of the rule because it is 
> not entirely clear how an automatic formatter will be able to check it.
> 
> Can you clarify whether clang-format would be able to handle your proposed 
> rule?

So, yesterday Bertrand pointed out a StackOverflow thread for this issue and if 
we use ReflowComments: false we should
be able to let the line as it is (not tested).

https://clang.llvm.org/docs/ClangFormatStyleOptions.html#reflowcomments



> 
> Cheers,
> 
> -- 
> Julien Grall


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.