On 16.01.2025 12:29, Sergiy Kibrik wrote: > 07.01.25 10:46, Jan Beulich: >> On 06.01.2025 19:09, Tamas K Lengyel wrote: >>> On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich <jbeul...@suse.com> wrote: >>>> >>>> On 06.01.2025 15:05, Tamas K Lengyel wrote: >>>>> On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich <jbeul...@suse.com> wrote: >>>>>> >>>>>> On 30.12.2024 07:30, Sergiy Kibrik wrote: >>>>>>> From: Stefano Stabellini <stefano.stabell...@amd.com> >>>>>>> >>>>>>> Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM >>>>>>> events >>>>>>> and monitoring support optional. >>>>>> >>>>>> Yet doesn't this end up in things becoming misleading? Don't we rather >>>>>> need a >>>>>> 2nd Kconfig option, with a dependency between the two? Or alternatively a >>>>>> rename of the existing option (to describe the higher-level feature >>>>>> rather >>>>>> than the lower level one)? Tamas, I'm particularly interested in knowing >>>>>> your >>>>>> view here as well. >>>>> >>>>> Thanks Jan, I was thinking the same thing. The dependency of these >>>>> subsystems is mem_access -> monitor -> vm_event. If the goal here is >>>>> to disable all three levels the ideal way would be to have separate >>>>> kconfig options for each level. It may be a bit too fine-grained >>>>> though on ARM since there are only two types of events for monitor >>>>> (SMC & mem_access) and only the monitor uses the vm_event channel (no >>>>> mem-sharing/paging on ARM). So if doing separate kconfig for each >>>>> individual feature is an overkill I would suggest using >>>>> CONFIG_VM_EVENT that disables all three levels, including both >>>>> mem_access & smc monitor hooks. >>>> >>>> Except that "disables all three levels" doesn't work, unless the other >>>> option(s) are promptless (and selected). I'd have expected VM_EVENT to >>>> maybe have a "depends on MEM_ACCESS", whereas a "select MEM_ACCESS" >>>> wouldn't make much sense as long as MEM_ACCESS can be enabled >>>> individually (with it being unclear to me whether such a configuration >>>> is actually useful in any way). >>> >>> Not sure I follow. None of these systems make sense to enable >>> individually. Without vm_event monitor/mem_access are useless, that's >>> why I would pick CONFIG_VM_EVENT as the option on ARM to disable all >>> three levels if we don't want to start splitting it into multiple >>> kconfig options (which I think may be an overkill here). >> >> Oh, okay, you suggest to replace MEM_ACCESS by VM_EVENT at the Kconfig >> level. That would be fine with me, so long as it's also appropriate on >> (in particular) x86. Then, if there was ever a 2nd use of mem-access, >> MEM_ACCESS could be re-introduced as a standalone option. > > Thanks Jan, > would it be ok to replace MEM_ACCESS with VM_EVENT everywhere at once, > including in defconfigs and automation script etc? Or such changes would > better be done gradually, starting with changing Kconfig only?
Things need to remain in sync throughout the tree, so I don't think you can leave out e.g. defconfigs when doing the renamed. Similarly stuff under automation/ may need changing at the same time. Jan
