This patch adds the BSS to the resource tree just as kernel text and kernel

data are in the resource tree. The main reason behind this is to avoid

crashkernel reservation in that area.
While it's not strictly necessary to have the BSS in the resource tree

(the actual collision detection is done in the reserve_bootmem() function

before), the usage of the BSS resource should be presented to the user

in /proc/iomem just as Kernel data and Kernel code.
Note: The patch currently is only implemented for x86 and ia64 (because

efi_initialize_iomem_resources() has the same signature on i386 and

ia64).
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---

 arch/ia64/kernel/efi.c     |    4 +++-

 arch/ia64/kernel/setup.c   |   14 +++++++++++---

 arch/x86/kernel/e820_32.c  |   18 +++++++++++++++---

 arch/x86/kernel/e820_64.c  |    3 ++-

 arch/x86/kernel/efi_32.c   |    4 +++-

 arch/x86/kernel/setup_32.c |    4 ++++

 arch/x86/kernel/setup_64.c |    9 +++++++++

 include/linux/efi.h        |    2 +-

 8 files changed, 48 insertions(+), 10 deletions(-)
--- a/arch/ia64/kernel/efi.c

+++ b/arch/ia64/kernel/efi.c

@@ -1090,7 +1090,8 @@ efi_memmap_init(unsigned long *s, unsign
 void

 efi_initialize_iomem_resources(struct resource *code_resource,

-			       struct resource *data_resource)

+			       struct resource *data_resource,

+			       struct resource *bss_resource)

 {

 	struct resource *res;

 	void *efi_map_start, *efi_map_end, *p;

@@ -1171,6 +1172,7 @@ efi_initialize_iomem_resources(struct re

 			 */

 			insert_resource(res, code_resource);

 			insert_resource(res, data_resource);

+			insert_resource(res, bss_resource);

 #ifdef CONFIG_KEXEC

                         insert_resource(res, &efi_memmap_res);

                         insert_resource(res, &boot_param_res);

--- a/arch/ia64/kernel/setup.c

+++ b/arch/ia64/kernel/setup.c

@@ -90,7 +90,12 @@ static struct resource code_resource = {

 	.name	= "Kernel code",

 	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM

 };

...
[ message continues ]

On Thu, 18 Oct 2007 13:15:36 +0200
As should these.  afaik they're the same on all architectures and even if

they have different names on some weird arch, an unused declaration won't
See, we keep on adding the same thing over and over again.
These problems are not introduced by your changes, of course.  But we really

should degunk this stuff sometime.
-

It's already ... the problem just was that IA64 uses _bss instead of

__bss_start. So I think we should change this. I verified that the

kernel still compiles with the patch below.
Thanks,

   Bernhard
---

[PATCH] Rename _bss to __bss_start
Rename _bss to __bss_start as on other architectures. That makes it possible to

use the <linux/sections.h> instead of own declarations. Also add __bss_stop

because that symbol exists on other architectures.
That patch applies to current git plus kexec-add-bss-to-resource-tree.patch in

-mm tree.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---

 arch/ia64/hp/sim/boot/bootloader.lds |    3 ++-

 arch/ia64/kernel/setup.c             |    3 +--

 arch/ia64/kernel/vmlinux.lds.S       |    3 ++-

 3 files changed, 5 insertions(+), 4 deletions(-)
--- a/arch/ia64/hp/sim/boot/bootloader.lds

+++ b/arch/ia64/hp/sim/boot/bootloader.lds

@@ -22,10 +22,11 @@ SECTIONS

   .sdata     : { *(.sdata) }

   _edata  =  .;
-  _bss = .;

+  __bss_start = .;

   .sbss      : { *(.sbss) *(.scommon) }

   .bss       : { *(.bss) *(COMMON) }

   . = ALIGN(64 / 8);

+  __bss_stop = .;

   _end = . ;
   /* Stabs debugging sections.  */

--- a/arch/ia64/kernel/setup.c

+++ b/arch/ia64/kernel/setup.c

@@ -95,7 +95,6 @@ static struct resource bss_resource = {

 	.name	= "Kernel bss",

 	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM

 };

-extern char _text[], _end[], _etext[], _edata[], _bss[];
 unsigned long ia64_max_cacheline_size;
@@ -206,7 +205,7 @@ static int __init register_memory(void)

 	code_resource.end   = ia64_tpa(_etext) - 1;

 	data_resource.start = ia64_tpa(_etext);

 	data_resource.end   = ia64_tpa(_edata) - 1;

-	bss_resource.start  = ia64_tpa(_bss);

+	bss_resource.start  = ia64_tpa(__bss_start);

 	bss_resource.end    = ia64_tpa(_end) - 1;

 	efi_initialize_iomem_resources(&code_resource, &data_resource,

 			&bss_resource);

--- a/arch/ia64/kernel/vmlinux.lds.S

+++ b/arch/ia64/kernel/vmlinux.lds.S

@@ -240,11 +240,12 @...
[ message continues ]

It's different on every architectures. Some don't have it at all (like

PPC64), and most of them have code_resource and data_resource static.

Instead of making the data on all architectures (that have it) global,

I'd like to make it static on x86.
See my attached patch.
Thanks,

   Bernhard
---
[PATCH] Remove extern declarations for code/data/bss resource
This patch removes the extern struct resource declarations for

data_resource, code_resource and bss_resource on x86 and declares

that three structures as static as done on other architectures like IA64.
On i386, these structures are moved to setup_32.c (from e820_32.c) because

that's code that is not specific to e820 and also required on EFI systems.

That makes the "extern" reference superfluous.
On x86_64, data_resource, code_resource and bss_resource are passed to

e820_reserve_resources() as arguments just as done on i386 and IA64. That also

avoids the "extern" reference and it's possible to make it static.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---

 arch/x86/kernel/e820_32.c  |   49 --------------------

 arch/x86/kernel/e820_64.c  |   11 ++--

 arch/x86/kernel/setup_32.c |  106 +++++++++++++++++++++++++++++++++++++++++++--

 arch/x86/kernel/setup_64.c |    6 +-

 4 files changed, 111 insertions(+), 61 deletions(-)
--- a/arch/x86/kernel/e820_32.c

+++ b/arch/x86/kernel/e820_32.c

@@ -37,26 +37,6 @@ unsigned long pci_mem_start = 0x10000000

 EXPORT_SYMBOL(pci_mem_start);

 #endif

 extern int user_defined_memmap;

-struct resource data_resource = {

-	.name	= "Kernel data",

-	.start	= 0,

-	.end	= 0,

-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM

-};

-

-struct resource code_resource = {

-	.name	= "Kernel code",

-	.start	= 0,

-	.end	= 0,

-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM

-};

-

-struct resource bss_resource = {

-	.name	= "Kernel bss",

-	.start	= 0,

-	.end	= 0,

-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM

-};
 static struct resource system_rom_resource = {

 	.name	= "System R...
[ message continues ]

Normally the "no externs in .c" rule doesn't apply to assembler or linker

script defined labels. That's because the point of the header file is to

type check them, but there is nothing to type check here.
-Andi

-

For linker generated symbols we have sections.h for this purpose.

The above symbols are all available if we do an:

#include <asm/sections.h>
This is the right fix in this case.
	Sam

-

The problem is that they're often the wrong type here. E.g. wrong signedness

etc. I ran into problems in the past where using this required ugly casts.
-Andi

-

But then we should fix them instead of working around the problem - no?
Grepping for _text shows that there are plenty of different ways to declare

that symbol extern - this does not look correct.
And I recall that extern char sym[] is considered correct by binutils

people - but I'm not 100% sure and google did not give me an appropriate hit.
	Sam

-

Yes, I generally prefer char[] - but only because gcc irritatingly

rejects void []...
    J

-

On Fri, 19 Oct 2007 00:18:13 +0200
An ancient memory tells me that these things are traditionally

declared as plain old int:
extern int start;

extern int edata;
etc.
However

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&...

disagrees with me.
http://www.psych.upenn.edu/~saul/parasite/man/man3/end.3.html agrees with me
http://docsrv.sco.com:507/en/man/html.S/end.S.html agrees with me
http://www.rocketaware.com/man/man3/end.3.htm agrees with me
http://bama.ua.edu/cgi-bin/man-cgi?etext+3C agrees with me
-

int is probably one of the less useful types. Typical operation is computing

the difference between two symbols in bytes. &int without cast would give

you a useless scaled size.
-Andi
-

They really don't have a specific type and using the type that happens to be convenient

to whatever calculation you want to do with it is useful.
-Andi

-