Re: External file structure

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 24 Jan 2023, Luca Fancellu wrote:
> Hi Michal, Stefano,
> 
> Thank you for your feedback,
> 
> >>> 
> >>> 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.
> 
> I’m ok to remove diverged, because in the end what matters is if the file is 
> still subject to backports
> (so it is diverging from the xen code style at least in part), if it is not 
> subject to backport it can be
> simply “converted” to the xen code style and scanned with the tools.
> 
> Here I’m wondering instead if the backport flag is enough to remove the file 
> form the scanned list,
> because if backport is true then we cannot deviate from findings or fix 
> false-positive, we could just
> fix issues in the original project and backport them to Xen (and sometimes 
> it’s not possible).
> Instead if the field is false, then it should be “converted” to the xen 
> codestyle and it can be subject of
> fixes as any other file “owned” by Xen.
> 
> What are your thoughts?

Yes, that could be a good idea. Maybe we could have a single field that
means:
1) not following the Xen coding style (probably following Linux coding style)
2) not scanning for MISRA C
3) probably not taking changes directly but backporting patches from
   Linux upstream. However taking or not-taking patches directly is
   usually on a case-by-case basis, so we could also avoid writing
   anything about backports and instead keeping to 1) and 2) only.