Re: External file structure

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 23 Jan 2023, Michal Orzel wrote:
> Hi Luca,
> 
> On 23/01/2023 11:28, Luca Fancellu wrote:
> > 
> > 
> > Hi all,
> > 
> > I’m starting a proposal for the external files that needs to be removed 
> > from the MISRA scan,
> > the work was originally started by Michal here:
> > https://patchwork.kernel.org/project/xen-devel/patch/20221116092032.4423-1-michal.orzel@xxxxxxx/
> Thanks for taking this on.
> 
> > so I started by that thread, the aim of this work is to have an initial 
> > format to start as soon as possible to
> > exclude the external files from the MISRA scan.
> > 
> > I think we can use the JSON format because it’s easy to integrate it with 
> > python and it’s easy to add/remove
> +1 for JSON format.
> 
> > fields from the structure without interfering with the other elements 
> > during time, so we can define a structure
> > now but if in the future we see the needs for additional field, we can just 
> > add them without changes to the
> > analysis script.
> > 
> > In my opinion many of these fields can be left empty in a first push, to 
> > let the script exclude the files and during
> > time with the contributions of the community we can add the missing 
> > informations.
> > I think it’s easier for the community to pick an entry, do some research to 
> > fill the gaps and push, instead to wait
> > until having all the informations before adding the entry.
> > 
> > 
> > This is my first though for the fields, let me know yours:
> > 
> > docs/misra/external-files.json:
> > {
> >   "version": "1.0”,
> >   "content": [
> >     {
> >       "path": "relative/path/from/xen/“,
> >       "diverged": false,
> >       "backport": "Y/N/?",
> These two fields are more for the community/maintainers rather than for MISRA.
> The reason is that we cannot deduct from that whether to exclude a file from 
> MISRA/code checkers or not.
> So we would need to have a separate field e.g. "exclude_from_checkers": 
> "true/false".
> This would also mean that we do not accept changes (normal changes, no 
> backports) for such files,
> e.g. to fix MISRA, coding style, etc.

It is true that we cannot deduct whether we should exclude a file from
MISRA checkers from "diverged" and "backport", so here we need one more
field like "exclude_from_checkers". A better name could be
"exclude_from_misrac".

Once we have that, what do we do with "diverged" and "backport"? I think
that we should just get rid of "diverged" because it is not very
actionable info and not a "scientific" metric anyway.

That leaves us only with "backport". "backport" is useful and I think we
should keep it.



> >       "origin_project": "URL to origin project",
> >       "origin_path": "relative path in the original project",
> >       "origin_revision": "revision in original project”
> >     }
> >   ]
> > }
> > 
> > 
> > Maybe, documentation for this file and the fields can reside in 
> > docs/misra/documenting-violations.rst, or
> I think a separate file would be needed because such json table would not 
> only be for MISRA benefit.

+1