Hi Babu, On 12/20/24 7:14 AM, Moger, Babu wrote: > Hi Reinette, > > On 12/19/2024 3:48 PM, Reinette Chatre wrote: >> Hi Babu, >> >> On 12/12/24 12:15 PM, Babu Moger wrote: >> >>> static inline struct rdt_hw_resource *resctrl_to_arch_res(struct rdt_resource *r) >>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> index 687d9d8d82a4..d54c2701c09c 100644 >>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> >> These functions are clearly monitoring related. Is there a reason why they are >> in rdtgroup.c and not in monitor.c? > > There is no specific reason. Most of these functions are called from user interface. User interface handlers are defined in rdtgroup.c. > Most, but not all of them, are, yes. With most operations triggered via user interface we'll end up with most code in the same file if trying to keep all code triggered by user space together. > All the code in this series is related to monitoring. We can move everything to monitor.c if you are ok with it. The read/write callbacks could stay with res_common_files[] to make their definition simpler. I think it would make things clear if these callback functions call into monitoring code located in monitor.c. Since you have been staring at this much longer, please let me know if you find this to actually make things harder to follow and find. Reinette
