On Thu, Apr 30, 2009 at 03:54:07PM -0400, Tim Abbott wrote:

(this patch series differs from v1 only in the CC list; some of the
architecture lists I sent the previous one to are moderated against
non-members; all replies should go to this version).

Here are the architecture-independent macro definitions needed for
to clean up the kernel's section names.  The overall diffstat from
this section name cleanup project is:

 96 files changed, 261 insertions(+), 503 deletions(-)

The decrease results from removing a lot of redundancy in the linker
scripts.

The long-term goal here is to add support for building the kernel with
-ffunction-sections -fdata-sections.  This requires renaming all the
magic section names in the kernel of the form .text.foo, .data.foo,
.bss.foo, and .rodata.foo to not have collisions with sections
generated for code like:

static int nosave = 0; /* -fdata-sections places in .data.nosave */
static void head(); /* -ffunction-sections places in .text.head */

Sam Ravnborg proposed that rather than just renaming all the sections
outright, we should start by first getting more control over the
section names used in the kernel so that we can later rename sections
without touching too many files.  These patch series implement that
cleanup.  Later, there will be another patch series to actually rename
the sections.

I'm hoping we can get just these macro definitions into 2.6.30 so that
the arch maintainers don't have to grab the macro definitions for
their trees while reviewing the patches for 2.6.31.

Shortly, I'm going to send one patch series for each of the
architectures updating those architectures to use these new macros
(and otherwise cleaning up section names on those architectures).

Hi Tim.

We agreed to get the common stuff and one architecture done before
proceeding with the rest.
Please stick to that plan so we avoid patch-bombing lkml + maintainers.

When we have this ready it will be a simple one-patch-per-arch to cover
the rest.

I will comment on your common patches for now.

	Sam