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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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)