Re: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols

Furkan Çalışkan <[email protected]> Wed, 5 Aug 2026 15:48:16 +0300
Newsgroups gmane.comp.emulators.xen.devel
Message-ID <[email protected]>
Hi Jan,

On 8/5/26 14:43, Jan Beulich wrote:
> On 04.08.2026 07:53, Furkan Caliskan wrote:
>> REGISTER_SCHEDULER(), schedulers[], NUM_SCHEDULERS, and the
>> per-arch SCHEDULER_ARRAY linker macro now register and hold
>> struct sched_ops instances rather than struct scheduler ones,
>> but still carry names describing the old type.
>>
>> Rename them to match the current behaviour.
>> No functional change.
>>
>> Signed-off-by: Furkan Caliskan <[email protected]>
>> ---
>>  xen/arch/arm/xen.lds.S      |  2 +-
>>  xen/arch/ppc/xen.lds.S      |  2 +-
>>  xen/arch/riscv/xen.lds.S    |  2 +-
>>  xen/arch/x86/xen.lds.S      |  2 +-
>>  xen/common/sched/arinc653.c |  2 +-
>>  xen/common/sched/core.c     | 33 +++++++++++++++++----------------
>>  xen/common/sched/credit.c   |  2 +-
>>  xen/common/sched/credit2.c  |  2 +-
>>  xen/common/sched/null.c     |  2 +-
>>  xen/common/sched/private.h  |  4 ++--
>>  xen/common/sched/rt.c       |  2 +-
>>  xen/include/xen/xen.lds.h   | 10 +++++-----
>>  12 files changed, 33 insertions(+), 32 deletions(-)
> 
> I'm not quite sure if all of this is really useful. In many (all?) places
> I think "scheduler" as a term is still quite applicable.
> 
> One (general) nit though: if already you touch malformed lines (overlong
> ones is which prompted this comment), please adjust them to be style-
> conformant.
> 
> Jan

The main reason I renamed those symbols was type consistency - since 
'struct scheduler' is now just the runtime per-cpupool object, keeping 
'schedulers[]' and 'REGISTER_SCHEDULER()' around to hold 'struct 
sched_ops' pointers felt like it might confuse someone reading the code 
later. 

That said, I get your point. At a higher level, those macros and linker 
arrays are still just registering scheduler implementations, so keeping 
the names is okay too. If the maintainers prefer keeping the existing 
naming, patch 1 can simply be taken on its own without the second patch. 

Juergen, what do you think here?

Thanks,
Furkan Caliskan