Re: [PATCH 2/2] x86/cpu-policy: move copy-in/-out functions to arch library

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.12.2025 12:22, Andrew Cooper wrote:
> On 22/12/2025 4:54 pm, Jan Beulich wrote:
>> --- a/tools/tests/cpu-policy/Makefile
>> +++ b/tools/tests/cpu-policy/Makefile
>> @@ -42,11 +42,15 @@ CFLAGS += $(APPEND_CFLAGS)
>>  
>>  LDFLAGS += $(APPEND_LDFLAGS)
>>  
>> -vpath %.c ../../../xen/lib/x86
>> +vpath %.c $(XEN_ROOT)/xen/lib/x86
>> +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib
>> +
>> +lib-y :=
>> +include $(XEN_ROOT)/xen/arch/x86/lib/Makefile.cpu-policy
>>  
>>  %.o: Makefile
>>  
>> -test-cpu-policy: test-cpu-policy.o msr.o cpuid.o policy.o
>> +test-cpu-policy: test-cpu-policy.o cpuid.o policy.o $(lib-y)
>>      $(CC) $^ -o $@ $(LDFLAGS)
>>  
>>  -include $(DEPS_INCLUDE)
>> --- a/xen/arch/x86/lib/Makefile
>> +++ b/xen/arch/x86/lib/Makefile
>> @@ -6,3 +6,5 @@ lib-y += generic-hweightl.o
>>  lib-y += memcpy.o
>>  lib-y += memset.o
>>  lib-y += scrub-page.o
>> +
>> +include $(srcdir)/Makefile.cpu-policy
>> --- /dev/null
>> +++ b/xen/arch/x86/lib/Makefile.cpu-policy
>> @@ -0,0 +1,2 @@
>> +lib-y += cp-copy-from-buffer.o
>> +lib-y += cp-copy-to-buffer.o
> 
> cp works as a name in source code because it's used by a type called
> cpu_policy.
> 
> In this case, cp with it's UNIX association makes the file name very weird.
> 
> 
> If we're going to be properly lib-ing the whole thing, then we're going
> to have enough TUs for a directory anyway.
> 
> So, I think we want xen/arch/x86/lib/cpu-policy/copy-{to,from}-buffer.o
> right from the outset.

I did consider this, but didn't like it very much because of this implication:
Either I need to touch arch.mk again to specify yet another archive to the
linker (not very scalable). Or I need to teach the build system to know to
combine archives from sub-directories into the parent directory's (i.e. follow
how built_in.o are being treated).

As you ask for it, I'll use the former of the two approaches (for likely
being simpler). Let me know if you disagree, or if you know of another good
approach.

> Also, I'd really prefer not to have things split between the old and new
> locations.  Everything wants to move in one go.
> 
> I'd suggest having one patch doing a wholesale move of xen/lib/x86 into
> xen/arch/x86/lib/cpu-policy and fixing up the vpath's, then a subsequent
> patch splitting copy-{to,from}-buffer.o out.

Can do; I would have thought that doing the move piecemeal ought to be okay.

Jan