Re: [PATCH v6 42/42] x86/resctrl: Add python script to move resctrl code to /fs/resctrl

[Reinette Chatre]

Hi James,

On 2/19/25 10:10 PM, Reinette Chatre wrote:
> Hi James,
> 
> On 2/7/25 10:18 AM, James Morse wrote:
>> To support more than one architecture resctrl needs to move from arch/x86
>> to live under fs. Moving all the code breaks any series on the mailing
>> list, so needs scheduling carefully.
>>
>> Maintaining the patch that moves all this code has proved labour intensive.
>> It's also near-impossible to review that no inadvertent changes have
>> crept in.
>>
>> To solve these problems, temporarily add a hacky python program that
>> lists all the functions that should move, and those that should stay.
>>
>> No attempt to parse C code is made, this thing tries to name 'blocks'
>> based on hueristics about the kernel coding style. It's fragile, but
> 
> (heuristics)
> 
>> good enough for its single use here.
>>
>> This only exists to show I have nothing up my sleeve.
>> I don't suggested this gets merged.
>>
>> The patch this script generaets has the following corner cases:
> (generates)
> 
>> * The original files are regenerated, which will add newlines that are
>>   not present in the original file.
>> * An trace-point header file the only contains boiler-plate is created
>>   in the arch and filesystem code. The parser doesn't know how to remove
>>   the includes for these - but its easy to 'keep' the file contents on
>>   the correct side. A follow-up patch will remove these files and their
>>   includes.
> 
> Related to the tracepoints I also noticed that there are some leftover
> tracing defines in files that no longer make use of tracing.
> For example, arch/x86/kernel/cpu/resctrl/monitor.c contains:
> #define CREATE_TRACE_POINTS
> #include monitor_trace.h
> 
> and fs/resctrl/pseudo_lock.c contains:
> #define CREATE_TRACE_POINTS
> #include "pseudo_lock_trace.h"
> 
> I assumed this will also be removed in this follow-up patch?
> 
>> * asm/cpu_device_id.h and a relative path for 'X86_CONFIG()' are kept
>>   in the filesystem code to ensure x86 builds. A follow-up patch will
>>   remove these.
>> * This script doesn't know how to move the documentation, and update the
>>   links in comments. A follow-up patch does this.
> 
> One unexpected thing I noticed is that fs/resctr/internal.h contains:
> #ifndef _ASM_X86_RESCTRL_INTERNAL_H
> #define _ASM_X86_RESCTRL_INTERNAL_H
> ...
> #endif /* _ASM_X86_RESCTRL_INTERNAL_H */

It looks like another item for this list of "corner cases" is that the
#include of all files need to be reviewed after the code move. There are
functions depending on a particular #include that are moved out of the .c
file but the (no longer needed) #include remains.

Reinette