On 2/19/25 09:52, Rik van Riel wrote: >> CPU_SUP_AMD selects X86_BROADCAST_TLB_FLUSH which depends on >> CPU_SUP_AMD which >> selects X86_BROADCAST_TLB_FLUSH which depends on CPU_SUP_AMD... >> >> Why do you really need yet another Kconfig symbol? Just whack >> X86_BROADCAST_TLB_FLUSH - it'll be enabled by default on everything >> anyway. > Dave specifically asked me to do things that way. Yeah, I'm in camp "moar Kconfig!" and Boris is in camp "too many Kconfigs!". I'm OK getting rid of the Kconfig as long as we have _some_ other way to nicely identify the INVLPGB code (which I think the X86_FEATURE gives us) _and_ that the overhead isn't too bad from leaving it compiled in all the time. The mmu_context is the one place that's kinda nasty without a Kconfig option. I guess it's only a few bytes but it's a super silly waste of a few bytes on i386, for example. I also really like the _logical_ clarity that comes from something like: +#ifdef CONFIG_X86_BROADCAST_TLB_FLUSH + u16 global_asid; + bool asid_transition; +#endif as opposed to: +#ifdef CONFIG_64BIT + /* Only used with X86_FEATURE_INVLPGB */ + u16 global_asid; + bool asid_transition; +#endif So, while I respect Boris's concern about Kconfig proliferation, I see the user-invisible ones (the ones without a prompt) as pretty harmless. Sorry for the maintainer crossfire, btw. I definitely don't want to be thrashing you around too much.
