On Mon Feb 16, 2026 at 12:01 PM CET, Jan Beulich wrote: >>> --- a/xen/arch/x86/mm/hap/Makefile >>> +++ b/xen/arch/x86/mm/hap/Makefile >>> @@ -2,5 +2,6 @@ obj-y += hap.o >>> obj-y += guest_walk_2.o >>> obj-y += guest_walk_3.o >>> obj-y += guest_walk_4.o >>> -obj-y += nested_hap.o >>> -obj-$(CONFIG_INTEL_VMX) += nested_ept.o >>> +nested-y := nested_hap.o >>> +nested-$(CONFIG_INTEL_VMX) += nested_ept.o >>> +obj-$(CONFIG_NESTED_VIRT) += $(nested-y) >> >> Why not use plain filter? >> >> -obj-y += nested_hap.o >> +obj-$(CONFIG_NESTED_VIRT) += nested_hap.o >> -obj-$(CONFIG_INTEL_VMX) += nested_ept.o >> +obj-$(filter $(CONFIG_NESTED_VIRT),$(CONFIG_INTEL_VMX)) += nested_ept.o > > It may have been like this in v1. Problem being that this leads to long lines, > which doesn't scale very well (and is - imo - harder to read). Especially when > you consider what happens when it's more than two settings that need checking. > The list approach easily scales to about anything (by using as many separate > lists as you need). > > Jan
I'd agree should we need more than 2 settings, long config parameter names or long filenames, but none of that applies here. It fits neatly in within 80 columns and the extra indirection bumps the cognitive load (subjectively speaking) way more than the single line does. Plus, it takes more vertical space. Even then, I'd rather have ifeq on the 3rd and/or 4th parameters and filter inside, which makes the group stand out much better and doesn't pollute the global namespace with even more names. And there's the matter of "filter" being in use very prevalently elsewhere. My .02, anyway. They are functionally equivalent, after all. Cheers, Alejandro
