Re: [PATCH 3/3] x86/cpu: don't gate PROCESSOR_SELECT with EXPERT

[Vincent Mailhol <mailhol@kernel.org>]

On 31/10/2026 at 14:58, Dave Hansen wrote:
> On 10/31/26 00:51, Vincent Mailhol wrote:
>> Remove the EXPERT dependency from PROCESSOR_SELECT. Make the option N by
>> default so that all x86 CPU types remain supported by default.
> 
> I actually kinda despise the vendor selection stuff in the first place.
> 
> It just causes problems. Like for protection keys. I diligently made it
> Intel-only when it was merged. But AMD came along and ruined my party
> when they added support for it. We had to go do more work later to make
> it available on AMD.

I think I am still missing the connection between the protection-key
example and keeping PROCESSOR_SELECT behind EXPERT. When AMD added
protection-key support, the dependency needed updating regardless of
whether vendor selection was visible outside EXPERT.

I understand that setting the correct CPU_SUP_* dependencies can be
challenging, but those dependencies are the developer's
responsibility. I don't think EXPERT is intended to hide symbols
whose dependencies are difficult to implement correctly in Kconfig. My
understanding is that it hides questions which require advanced
knowledge from the user configuring the kernel.

> It's also one of those things that inevitably hides build problems.
> 
> Hiding it all behind EXPERT seems very prudent to me. I'm not seeing
> justification in this series to change that.

My justification is that the configuration process currently seems
backward. For example, an AMD-only build doesn't need
MITIGATION_CALL_DEPTH_TRACKING. Today, the user would need to navigate
the "Mitigations for CPU vulnerabilities" menu and understand that
option to disable it individually. It seems easier to ask which CPU
vendors need to be supported and let Kconfig exclude features specific
to the other vendors. The same reasoning applies to other symbols with
CPU_SUP_* dependencies.

Generally speaking, my opinion is that EXPERT should be applied to the
child symbols rather than their parents. The deeper we go in the
dependency tree, the more specialised the options become and the more
expertise they require.

I agree that keeping vendor selection behind EXPERT reduces exposure
to configuration combinations that may receive limited testing. But if
there is a bug in Kconfig, is limiting exposure the correct strategy?
In the end, it just hides a genuine bug without addressing the root
cause.


Yours sincerely,
Vincent Mailhol