Re: [RFC] docs/misra: List files in Xen originated from external sources

[Michal Orzel <michal.orzel@xxxxxxx>]

Hi Jan,

Thanks for looking at it.

On 17/11/2022 11:03, Jan Beulich wrote:
> 
> 
> On 16.11.2022 10:20, Michal Orzel wrote:
>> --- /dev/null
>> +++ b/docs/misra/external-files.txt
>> @@ -0,0 +1,70 @@
>> +External files in Xen
>> +=====================
>> +
>> +The following table lists files present in the Xen codebase that originated
>> +from external sources e.g. Linux kernel. The purpose of this table is to:
>> + - keep track of the external files in the Xen codebase,
>> + - help with the review process (e.g. changes done to the files that did not
>> +   diverge, shall be first submitted to the external projects and then
>> +   backported to Xen),
>> + - act as a base for listing files to exclude from MISRA checkers.
>> +
>> +NOTES:
>> +1) The files shall be listed in alphabetical order.
> 
> But then you don't?
True, it is alphabetical order with directories having a precedence.

> 
>> +2) The origin of the files derived from the projects other than Linux, shall
>> +   be specified within the () placed next to the path.
> 
> Might it be more generally useful to have another column, then not only
> stating the project but also the path it lives at there (or lived at the
> time of cloning)?
We though about it. Would be a good idea but can be quite challenging for files
that appeared in Xen before switching to git (difficult to establish the time 
of cloning in such cases).

> 
>> +3) The table shall be updated when importing new files from external 
>> projects.
>> +4) At the moment, only the source files are listed in the table.
>> +
>> +| Relative path to xen/                     | Diverged from | Subject to    
>>    |
>> +|                                           | origin? [Y/N] | backports? 
>> [Y/N] |
>> ++-------------------------------------------+---------------+------------------+
>> +| arch/arm/arm64/cpufeature.c               | N             | Y             
>>    |
>> +| arch/arm/arm64/insn.c                     | N             | Y             
>>    |
>> +| arch/arm/arm64/lib/find_next_bit.c        | N             | Y             
>>    |
>> +| arch/x86/acpi/boot.c                      | Y             | ?             
>>    |
>> +| arch/x86/acpi/lib.c                       | ?             | ?             
>>    |
> 
> This was simply split off from boot.c, which I'd be inclined to take to
> mean Y in the "diverged" column. In the backports column I'd prefer to
> keep ? for both, or any other indicator taken to mean "maybe / uncertain".
> 
> What about arch/x86/acpi/cpufreq/* and other stuff in arch/x86/acpi/?
> 
>> +| arch/x86/cpu/mcheck/mce-apei.c            | N             | Y             
>>    |
>> +| arch/x86/cpu/mcheck/non-fatal.c           | ?             | Y             
>>    |
> 
> Even before disappearing in 2.6.32 the file was different from Linux'es,
> simply because we don't have anything like schedule_delayed_work(). So
> it's pretty clearly Y for "diverged".
> 
>> +| arch/x86/cpu/mtrr/*                       | Y             | N             
>>    |
>> +| arch/x86/cpu/amd.c                        | Y             | N             
>>    |
>> +| arch/x86/cpu/centaur.c                    | Y             | N             
>>    |
>> +| arch/x86/cpu/common.c                     | Y             | N             
>>    |
>> +| arch/x86/cpu/hygon.c                      | Y             | N             
>>    |
>> +| arch/x86/cpu/intel_cacheinfo.c            | Y             | Y             
>>    |
>> +| arch/x86/cpu/intel.c                      | Y             | N             
>>    |
>> +| arch/x86/cpu/mwait-idle.c                 | Y             | Y             
>>    |
>> +| arch/x86/genapic/*                        | Y             | N             
>>    |
>> +| arch/x86/x86_64/mmconf-fam10h.c           | N             | Y             
>>    |
>> +| arch/x86/dmi_scan.c                       | Y             | ?             
>>    |
>> +| arch/x86/mpparse.c                        | Y             | ?             
>>    |
> 
> Like above I'd like to keep ? (or alike) here, as neither Y nor N are
> fully accurate.
> 
>> +| arch/x86/srat.c                           | Y             | N             
>>    |
> 
> What about common/cpu.c?
> 
>> +| common/libfdt/* (libfdt)                  | N             | Y             
>>    |
>> +| common/lz4/decompress.c                   | N             | Y             
>>    |
>> +| common/ubsan/ubsan.c                      | Y             | Y             
>>    |
>> +| common/xz/*                               | N             | Y             
>>    |
>> +| common/zstd/*                             | N             | Y             
>>    |
>> +| common/bitmap.c                           | N             | Y             
>>    |
>> +| common/bunzip2.c                          | N             | Y             
>>    |
>> +| common/earlycpio.c                        | N             | Y             
>>    |
>> +| common/inflate.c                          | N             | Y             
>>    |
> 
> What about common/notifier.c?
> 
>> +| common/radix-tree.c                       | N             | Y             
>>    |
> 
> What about common/rcupdate.c? (Stopping at this in this regard:
> It's unclear by what criteria you have gone. Even as simple an
> indicator as "Copyright (C) ... Linus Torvalds" was apparently not
Please see [1]

> used. Similarly mentioning criteria for considering a file
> "diverged" would be very helpful to spell out, even if there's
> likely some fuzziness involved there.)

We would need to pre-define some criteria to avoid having a long justifications.
Any ideas?

> 
>> +| common/un*.c                              | N             | Y             
>>    |
>> +| crypto/rijndael.c (OpenBSD)               | N             | Y             
>>    |
>> +| crypto/vmac.c (public domain)             | N             | Y             
>>    |
>> +| drivers/acpi/apei/*                       | N             | Y             
>>    |
> 
> I'm not sure of the N here.
> 
>> +| drivers/acpi/tables/*                     | N             | Y             
>>    |
>> +| drivers/acpi/utilities/*                  | N             | Y             
>>    |
>> +| drivers/acpi/hwregs.c                     | N             | Y             
>>    |
>> +| drivers/acpi/numa.c                       | ?             | Y             
>>    |
> 
> Y
> 
>> +| drivers/acpi/osl.c                        | Y             | Y             
>>    |
>> +| drivers/acpi/reboot.c                     | N             | Y             
>>    |
>> +| drivers/acpi/tables.c                     | ?             | Y             
>>    |
> 
> Y
> 
> What about drivers/cpufreq/*, drivers/char/ehci-dbgp.c,
> drivers/char/xhci-dbc.c, and drivers/video/font*? What about some of
> the stuff under tools/, especially tools/kconfig/?

[1]
For the first shot, the criteria was to list files using different coding style 
than Xen,
especially the ones using tabs instead of spaces. As I indicated before, the 
list may not be
completed, hence a gentle ask to list the missing ones. Some of the files you 
mentioned
use Xen coding style + there is no information in the git history that they 
originated from
external sources. This is why, the maintainers who are the addressee of this 
RFC should have
a better knowledge of the origin of such files.

As for the files under tools/, FWICS they are being filtered-out from MISRA 
checks, hence I
did not list them.

> 
> Jan

~Michal