Re: [PATCH v2 1/2] x86/cpu-policy: move CPU policy library code

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 24/02/2026 8:58 am, Jan Beulich wrote:
> On 24.02.2026 09:53, Roger Pau Monné wrote:
>> On Tue, Feb 24, 2026 at 07:54:29AM +0100, Jan Beulich wrote:
>>> On 23.02.2026 20:00, Andrew Cooper wrote:
>>>> On 02/02/2026 4:26 pm, Jan Beulich wrote:
>>>>> On 02.02.2026 16:47, Andrew Cooper wrote:
>>>>>> On 07/01/2026 2:17 pm, Jan Beulich wrote:
>>>>>>> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
>>>>>>> index 0203138a819a..be6c76d2934b 100644
>>>>>>> --- a/xen/arch/x86/arch.mk
>>>>>>> +++ b/xen/arch/x86/arch.mk
>>>>>>> @@ -4,6 +4,7 @@
>>>>>>>  export XEN_IMG_OFFSET := 0x200000
>>>>>>>  
>>>>>>>  ARCH_LIBS-y += arch/x86/lib/lib.a
>>>>>>> +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a
>>>>>> This wants to extend ARCH_LIBS-y surely?  Is this a rebasing oversight?
>>>>> No, this was deliberate. The functions here are different from those in
>>>>> arch/x86/lib/lib.a. We don't need to fear collision with "common code"
>>>>> ones. Hence I preferred to use the more "normal" placement into what's
>>>>> passed to the linker.
>>>> I agree that we don't have the explicit ordering requirement that we
>>>> have with arch/x86/lib/lib.a.
>>>>
>>>> But, it still reads as bogus to be putting arch/x86/lib/cpu-policy/lib.a
>>>> in the non-ARCH list.
>>>>
>>>> What difference is there having this a little earlier in the linker
>>>> arguments?  Nothing AFAICT.
>>> Indeed. The sole reason why I'd prefer things as presented is that putting
>>> stuff in ARCH_LIBS should imo be the special case (i.e. requiring a special
>>> reason), while putting things in ALL_LIBS should be the default.
>> I agree with Andrew that it feels weird that arch/x86/lib/lib.a is
>> placed in ARCH_LIBS-y and arch/x86/lib/cpu-policy/lib.a is placed in
>> ALL_LIBS-y.  If we want to do it that way it needs a comment
>> explaining why they are placed in different list, otherwise it seems
>> like a typo on first sight, and it's likely to confuse people in the
>> future.
> Well, I'll (reluctantly) change then.

Thanks.  With that done, Reviewed-by: Andrew Cooper
<andrew.cooper3@xxxxxxxxxx>