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.coop...@citrix.com>
>>> ---
>>> CC: Jan Beulich <jbeul...@suse.com>
>>> CC: Roger Pau Monné <roger....@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 <jbeul...@suse.com>
Jan
