Re: [PATCH 2/2] x86: move / split usercopy.c to / into arch-specific library

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.11.2025 14:56, Andrew Cooper wrote:
> On 26/11/2025 1:24 pm, Jan Beulich wrote:
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index 61e2293a467e..76540d77e55f 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -72,7 +72,6 @@ obj-y += time.o
>>  obj-y += traps-setup.o
>>  obj-y += traps.o
>>  obj-$(CONFIG_INTEL) += tsx.o
>> -obj-y += usercopy.o
>>  obj-y += x86_emulate.o
>>  obj-$(CONFIG_TBOOT) += tboot.o
>>  obj-y += hpet.o
> 
> There's
> 
> # Allows usercopy.c to include itself
> $(obj)/usercopy.o: CFLAGS-y += -iquote .
> 
> which looks like it wants moving too.

It doesn't need moving, and I apparently sent a stale patch. This hunk is
simply missing:

@@ -93,9 +92,6 @@ hostprogs-y += efi/mkreloc
 
 $(obj)/efi/mkreloc: HOSTCFLAGS += -I$(srctree)/include
 
-# Allows usercopy.c to include itself
-$(obj)/usercopy.o: CFLAGS-y += -iquote .
-
 $(obj)/x86_emulate.o: CFLAGS-y += -Os
 ifneq ($(CONFIG_HVM),y)
 $(obj)/x86_emulate.o: CFLAGS-y += -Wno-unused-label

> But, given that this presumably compiles, doesn't it mean we've got a
> search path problem anyway?

Iirc the need for the piece above was because of using __FILE__ with
#include, which now we don't anymore. Or maybe it was a leftover altogether.
Anyway, I don't see there being a search path problem, as #include "..." (as
used now) would better always work.

Jan