[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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/