linux-mips
[Top] [All Lists]

[RFC] Add __initbss section

To: Ralf Baechle <ralf@linux-mips.org>, "Maciej W. Rozycki" <macro@linux-mips.org>, Geert Uytterhoeven <geert@linux-m68k.org>
Subject: [RFC] Add __initbss section
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Date: Thu, 11 Oct 2007 11:52:30 +0200
Cc: linux-mips <linux-mips@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; bh=w2ThYS9RQI6HuRrAWw6Ha9mrJISrzZ5HulZc/31dcFY=; b=DS5HZHkSdnpevxA9rHz9BXyokilD1VX8YBmWGDt6UsNitDfTU6HZQaL/Ft4CtZNdyPBO/3bUMU7THkkX/Hf2B0u3f7Gn9Vg4qSYO3fkaK3uwTf+WhYs9YNZaxgyNPMo4l+mhUDaTRNXW3TSLm0yxrBxRzoXQPtJ66O6KaDaVIiE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=OFlvwu1nX4QGZoXMd/D7D0l07RAw5YjOMWKuEaH0Gk9AGoQ8YUuogdFStAna7uIF6XKZr63j9tIx53piaK+NH26UTDq9IRxSUIjLvLBpkcpMCQG9uQDXXfXSTCROtP83+Jol+jQFA4m76ONE7jqwNW5IQl5SC2kVBQDhEy7DX1M=
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.5 (X11/20070719)
Hi,

As discussed previously, it seems a good idea to create a new init
section .init.bss that store uninitialized data used only at boot
time. That way, we can avoid to embed these uninitialized data in the
Linux image since it's totaly useless.

As a good candidate for using this, is tlbex.c. This file allocates a
couple of big arrays that don't need to be part of the init data
section since they're not initialized and they're currently only used
at boot time.

So this patchset does this but the result looks weird: I tried to
apply this patch on top of the patchset:

---8<---

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index a61246d..8271eab 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -743,11 +743,11 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum 
label_id l)
  * We deliberately chose a buffer size of 128, so we won't scribble
  * over anything important on overflow before we panic.
  */
-static __initdata u32 tlb_handler[128];
+static __initbss u32 tlb_handler[128];
 
 /* simply assume worst case size for labels and relocs */
-static __initdata struct label labels[128];
-static __initdata struct reloc relocs[128];
+static __initbss struct label labels[128];
+static __initbss struct reloc relocs[128];

--->8---

and the kernel image is bigger after the patch is applied !

$ ls -l vmlinux*
-rwxrwxr-x 1 fbuihuu fbuihuu 2503324 2007-10-11 11:41 vmlinux*
-rwxrwxr-x 1 fbuihuu fbuihuu 2503264 2007-10-11 11:41 vmlinux~old*

Could anybody explain me why ? The time is missing and I probably
couldn't investigate into this until this weekend. 

Also not that with the current patchset applied, there are now 2
segments that need to be loaded, hopefully it won't cause any issues
with any bootloaders out there that would assume that an image has
only one segment...

Other question: I noticed that the exit.data section is not
discarded. Could anybody give me the reason why ?

                Franck

<Prev in Thread] Current Thread [Next in Thread>