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

[Vincent Mailhol]

Hi Dave, Boris,

On 01/11/2026 at 12:26, Vincent Mailhol wrote:
> 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.

Have you had a chance to read my replies?

I wrote patch 3 because, as a user configuring a kernel for my own
machine, I felt that choosing the supported CPU vendors directly
improved the configuration experience.

If, after considering my arguments, you still prefer to keep
PROCESSOR_SELECT behind EXPERT, that's fine with me. In that case, would
you consider picking up patches 1 and 2 independently?


Yours sincerely,
Vincent Mailhol