It is mostly sorted, but there are anomalies. Eliminating them gives
people fewer excuses to (blindly) add to the end of the list.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Of course sorting with underscores or dashes in filenames is always going
to be ambiguous: Some may prefer C locale sorting, some may prefer sorting
as if non-alphanumeric characters simply weren't there, and some may
prefer yet different criteria. But those corner cases probably aren't even
worth formally settling on a particular model.

x86_emulate.o coming rather late in the list may want considering to make
an exception for: It takes comparably long to build, and hence it may be
best if it got scheduled as early as possible in a parallel make.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -33,21 +33,22 @@ obj-y += emul-i8254.o
 obj-y += extable.o
 obj-y += flushtlb.o
 obj-$(CONFIG_GDBSX) += gdbsx.o
+obj-y += hpet.o
 obj-y += hypercall.o
 obj-y += i387.o
 obj-y += i8259.o
-obj-y += io_apic.o
-obj-$(CONFIG_LIVEPATCH) += livepatch.o
-obj-y += msi.o
-obj-y += msr.o
 obj-$(CONFIG_INDIRECT_THUNK) += indirect-thunk.o
 obj-$(CONFIG_RETURN_THUNK) += indirect-thunk.o
 obj-$(CONFIG_PV) += ioport_emulate.o
+obj-y += io_apic.o
 obj-y += irq.o
+obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
 obj-y += mm.o x86_64/mm.o
 obj-$(CONFIG_VM_EVENT) += monitor.o
 obj-y += mpparse.o
+obj-y += msi.o
+obj-y += msr.o
 obj-y += nmi.o
 obj-y += numa.o
 obj-y += pci.o
@@ -62,14 +63,13 @@ obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
 obj-$(CONFIG_SYSCTL) += sysctl.o
+obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += time.o
 obj-y += traps-setup.o
 obj-y += traps.o
 obj-$(CONFIG_INTEL) += tsx.o
-obj-y += x86_emulate.o
-obj-$(CONFIG_TBOOT) += tboot.o
-obj-y += hpet.o
 obj-$(CONFIG_VM_EVENT) += vm_event.o
+obj-y += x86_emulate.o
 obj-y += xstate.o
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)

On 24/06/2026 8:50 am, Jan Beulich wrote:
> It is mostly sorted, but there are anomalies. Eliminating them gives
> people fewer excuses to (blindly) add to the end of the list.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Do you want me to pull this into for-next?  I'll (hopefully) be queuing
the series which caused you to notice it into for-next in due course.

> ---
> Of course sorting with underscores or dashes in filenames is always going
> to be ambiguous: Some may prefer C locale sorting, some may prefer sorting
> as if non-alphanumeric characters simply weren't there, and some may
> prefer yet different criteria. But those corner cases probably aren't even
> worth formally settling on a particular model.

That's not a relevant consideration in this patch is it?  I see no
ambiguity.

Also, if in doubt, surely always C locale?  Pretending that _- aren't
present is definitely a bad sorting algorithm.

> x86_emulate.o coming rather late in the list may want considering to make
> an exception for: It takes comparably long to build, and hence it may be
> best if it got scheduled as early as possible in a parallel make.

Move it to the front with a comment saying "Really a subdir, but not
expressed in that way" or something?

~Andrew

On 24.06.2026 11:10, Andrew Cooper wrote:
> On 24/06/2026 8:50 am, Jan Beulich wrote:
>> It is mostly sorted, but there are anomalies. Eliminating them gives
>> people fewer excuses to (blindly) add to the end of the list.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> Do you want me to pull this into for-next?  I'll (hopefully) be queuing
> the series which caused you to notice it into for-next in due course.

Feel free if you want to, but I'll get this in soon after branching anyway.

>> ---
>> Of course sorting with underscores or dashes in filenames is always going
>> to be ambiguous: Some may prefer C locale sorting, some may prefer sorting
>> as if non-alphanumeric characters simply weren't there, and some may
>> prefer yet different criteria. But those corner cases probably aren't even
>> worth formally settling on a particular model.
> 
> That's not a relevant consideration in this patch is it?  I see no
> ambiguity.

I thought io_apic.o vs ioport_emulate.o would have been affected, but they
aren't.

> Also, if in doubt, surely always C locale?  Pretending that _- aren't
> present is definitely a bad sorting algorithm.

ls looks to be using this by default, so it can't be all that bad.

>> x86_emulate.o coming rather late in the list may want considering to make
>> an exception for: It takes comparably long to build, and hence it may be
>> best if it got scheduled as early as possible in a parallel make.
> 
> Move it to the front with a comment saying "Really a subdir, but not
> expressed in that way" or something?

We have

obj-y += x86_emulate/

there, so excusing this by what you say would feel somewhat wrong.
Mentioning in a comment that it's there for build performance would look
okay to me. I raised the question mainly to get an understanding whether
such an exception would be acceptable at all.

Jan

On 24/06/2026 11:37 am, Jan Beulich wrote:
> On 24.06.2026 11:10, Andrew Cooper wrote:
>> On 24/06/2026 8:50 am, Jan Beulich wrote:
>>> x86_emulate.o coming rather late in the list may want considering to make
>>> an exception for: It takes comparably long to build, and hence it may be
>>> best if it got scheduled as early as possible in a parallel make.
>> Move it to the front with a comment saying "Really a subdir, but not
>> expressed in that way" or something?
> We have
>
> obj-y += x86_emulate/
>
> there, so excusing this by what you say would feel somewhat wrong.

Wait, we've got both that and the higher level x86_emulate.c reaching
into that subdir?

Can't we just fix that?  The higher x86_emulate.c is almost empty, and
lost it's main purpose when you started splitting decode out.

That way we no longer have a special case, and no need to excuse it. 
Subdirs always get entered first.

~Andrew

On 24.06.2026 12:40, Andrew Cooper wrote:
> On 24/06/2026 11:37 am, Jan Beulich wrote:
>> On 24.06.2026 11:10, Andrew Cooper wrote:
>>> On 24/06/2026 8:50 am, Jan Beulich wrote:
>>>> x86_emulate.o coming rather late in the list may want considering to make
>>>> an exception for: It takes comparably long to build, and hence it may be
>>>> best if it got scheduled as early as possible in a parallel make.
>>> Move it to the front with a comment saying "Really a subdir, but not
>>> expressed in that way" or something?
>> We have
>>
>> obj-y += x86_emulate/
>>
>> there, so excusing this by what you say would feel somewhat wrong.
> 
> Wait, we've got both that and the higher level x86_emulate.c reaching
> into that subdir?
> 
> Can't we just fix that?  The higher x86_emulate.c is almost empty, and
> lost it's main purpose when you started splitting decode out.

It's emptier for you than for me, as I've put some AMX stuff there which
otherwise would require #ifdef-ary elsewhere. I guess I can see about
moving that and then indeed ...

> That way we no longer have a special case, and no need to excuse it. 
> Subdirs always get entered first.

... try to get to this state.

Jan

On 24.06.2026 12:45, Jan Beulich wrote:
> On 24.06.2026 12:40, Andrew Cooper wrote:
>> On 24/06/2026 11:37 am, Jan Beulich wrote:
>>> On 24.06.2026 11:10, Andrew Cooper wrote:
>>>> On 24/06/2026 8:50 am, Jan Beulich wrote:
>>>>> x86_emulate.o coming rather late in the list may want considering to make
>>>>> an exception for: It takes comparably long to build, and hence it may be
>>>>> best if it got scheduled as early as possible in a parallel make.
>>>> Move it to the front with a comment saying "Really a subdir, but not
>>>> expressed in that way" or something?
>>> We have
>>>
>>> obj-y += x86_emulate/
>>>
>>> there, so excusing this by what you say would feel somewhat wrong.
>>
>> Wait, we've got both that and the higher level x86_emulate.c reaching
>> into that subdir?
>>
>> Can't we just fix that?  The higher x86_emulate.c is almost empty, and
>> lost it's main purpose when you started splitting decode out.
> 
> It's emptier for you than for me, as I've put some AMX stuff there which
> otherwise would require #ifdef-ary elsewhere. I guess I can see about
> moving that and then indeed ...
> 
>> That way we no longer have a special case, and no need to excuse it. 
>> Subdirs always get entered first.
> 
> ... try to get to this state.

x86/x86_emulate/x86_emulate.c has no #ifdef-ary at its top so far. Sites
#include-ing the file are responsible for carrying all prereq #include-s
(i.e. ones needed on top of what x86/x86_emulate/private.h supplies). Are
we happy to give up on that and have #ifdef-ed #include-s (and alike)
at the top of x86/x86_emulate/x86_emulate.c? (For AMX there would then
also be a couple of static items in a __XEN__-only code fragment.)

Jan