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). Jan
