[PATCH 0/4] hard_smp_processor_id overhaul (v.2)

[PATCH 0/4] hard_smp_processor_id overhaul (v.2)

[Fernando Luis Vázquez Cao]

This new version (v.2) fixes generic arch i386 up build, has (hopefully)
clearer explanations, and does not break git bisect searches.
---
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a particular hardware ID (often 0)
(usually referred to as BSP on some architectures) is not valid anymore.
The reason being that the dump capture kernel boots on the crashed CPU
(the CPU that invoked crash_kexec), which may be or may not be that
particular CPU.

As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
systems (see "linux/smp.h") is not correct.

This patch-set does the following:

1- Remove hardcoding of hard_smp_processor_id on UP systems (patch 1).

2- Move definition of hard_smp_processor_id for the UP case to
architecture specific code ("asm/smp.h") where it belongs, so that each
architecture can provide its own implementation (patch 1).

3- Ask the hardware when possible to obtain the hardware processor id on
i386 (patch 2), x86_64 (patch 3), and ia64 (patch 4), independently of
whether CONFIG_SMP is set or not.

I guess that something similar could be done for the rest of the
architectures, but since I am not an expert in all of them I am just
moving the definition of hard_smp_processor_id to "asm/smp.h" for those.
Of course, help from the respective maintainers to fill this gap would
be greatly appreciated.

The patches have been tested on i386, x86_64, and ia64.

Re: [PATCH 0/4] hard_smp_processor_id overhaul (v.2)

[Simon Horman]

On Wed, Apr 04, 2007 at 05:51:07PM +0900, Fernando Luis Vázquez Cao wrote:
> This new version (v.2) fixes generic arch i386 up build, has (hopefully)
> clearer explanations, and does not break git bisect searches.
> ---
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a particular hardware ID (often 0)
> (usually referred to as BSP on some architectures) is not valid anymore.
> The reason being that the dump capture kernel boots on the crashed CPU
> (the CPU that invoked crash_kexec), which may be or may not be that
> particular CPU.
> 
> As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> systems (see "linux/smp.h") is not correct.
> 
> This patch-set does the following:
> 
> 1- Remove hardcoding of hard_smp_processor_id on UP systems (patch 1).
> 
> 2- Move definition of hard_smp_processor_id for the UP case to
> architecture specific code ("asm/smp.h") where it belongs, so that each
> architecture can provide its own implementation (patch 1).
> 
> 3- Ask the hardware when possible to obtain the hardware processor id on
> i386 (patch 2), x86_64 (patch 3), and ia64 (patch 4), independently of
> whether CONFIG_SMP is set or not.
> 
> I guess that something similar could be done for the rest of the
> architectures, but since I am not an expert in all of them I am just
> moving the definition of hard_smp_processor_id to "asm/smp.h" for those.
> Of course, help from the respective maintainers to fill this gap would
> be greatly appreciated.
> 
> The patches have been tested on i386, x86_64, and ia64.

Sorry for the delay in getting back to you, I've been on the road.

All these patches seem fine to me.