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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.