Re: [XEN PATCH][for-4.19 1/2] xen: introduce a deviation for Rule 11.9

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 07/10/2023 02:33, Stefano Stabellini wrote:
> On Fri, 6 Oct 2023, Julien Grall wrote:
>> On 06/10/2023 10:58, Nicola Vetrini wrote:
>> > On 06/10/2023 11:27, Julien Grall wrote:
>> > > Hi,
>> > >
>> > > On 05/10/2023 09:45, Nicola Vetrini wrote:
>> > > > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
>> > > > compile-time check to detect non-scalar types; its usage for this
>> > > > purpose is documented in rules.rst as an exception.
>> > > Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing
>> > > that other analysis tool may point out the same error and therefore it
>> > > would seem more appropriate to use a deviation.
>> > >
>> > > This would also avoid having a specific rule in the Eclair
>> > > configuration for __ACCESS_ONCE().
>> > >
>> >
>> > I figured a single accepted use would benefit from an explicit exclusion.
>> > I can rework it to use an in-code comment to deviate, in whatever form that
>> > comment may be
>> > (still with some bits of ECLAIR-specific configuration anyway, as discussed
>> > for R2.1).
>> 
>> I think it would be preferrable to have a deviation in the code. This 
>> would be
>> helpful for other analysis tools.
> 
> Yes exactly, see my reply:
> https://marc.info/?l=xen-devel&m=169663696228889
> 
> I know I acked the patch but I agree with Julien. A deviation as an
> in-code comment (SAF-x-safe) is always the best option. If that doesn't
> work, we cannot keep adding stuff in the notes section of rules.rst. It
> doesn't scale. We should create a new document, like deviations.rst, or
> add a new section at the bottom of documenting-violations.rst or
> possibly safe.json.

I'll rebase this patch with an entry in deviations.rst, so that this 
applies to staging
cleanly.

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