Re: [PATCH 3/6] x86/match-cpu: Introduce X86_MATCH_VFM() and convert intel_idle_ids[]

[Jan Beulich <jbeulich@suse.com>]

On 17.07.2025 19:39, Andrew Cooper wrote:
> On 17/07/2025 8:35 am, Jan Beulich wrote:
>> On 16.07.2025 19:31, Andrew Cooper wrote:
>>> mwait-idle's ICPU() is the most convenient place to get started.  Introduce
>>> X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
>>>
>>> This involves match-cpu.h including more headers, which in turn allows us to
>>> drop a few.
>> intel-cpu.h doesn't really need to move, does it? Conceivably there can be users
>> of match-cpu.h which don't need the Intel constants. Hence no point in forcing
>> them to see those.
> 
> There's no point not to.  All users of x86_cpu_id want the Intel names. 
> I've already restricted it to only 5 TUs.
> 
> Even if we do get some AMD names (and I'm not entirely sure how that
> would end up looking), it's just a few defines.

It's just a (slowly growing set of a) few, yes. Still goes against our
desire the limit #include dependencies.

>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> ---
>>> CC: Jan Beulich <JBeulich@suse.com>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> We now have X86_FEATURE_ANY and X86_FEATURE_ALWAYS as aliases of LM.  Given
>>> the contexts they're used in, I've left the naming as-is.
>> What's wrong with sticking to ALWAYS, which we already have?
> 
> For alternatives, something like:
> 
>     alternative("", "foo", X86_FEATURE_ALWAYS);
> 
> is correct in context.  However:
> 
>     X86_MATCH_?(..., X86_FEATURE_ALWAYS, ...);
> 
> is borderline grammatically wrong, and ANY is a better name to use.

Well, I don't necessarily agree, but then the extra name also isn't
a severe problem. It was actually you who called out the redundancy.
In any event:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan