All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Alon Bar-Lev <alon.barlev@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, bwalle@suse.de,
	rmk+lkml@arm.linux.org.uk, spyro@f2s.com,
	davej@codemonkey.org.uk, hpa@zytor.com, Riley@williams.name,
	tony.luck@intel.com, geert@linux-m68k.org, zippel@linux-m68k.org,
	ralf@linux-mips.org, matthew@wil.cx, grundler@parisc-linux.org,
	kyle@parisc-linux.org, paulus@samba.org, schwidefsky@de.ibm.com,
	lethal@linux-sh.org, davem@davemloft.net,
	uclinux-v850@lsi.nec.co.jp, ak@muc.de, vojtech@suse.cz,
	chris@zankel.net, len.brown@intel.com, lenb@kernel.org,
	herbert@gondor.apana.org.au, viro@zeniv.linux.org.uk,
	bzolnier@gmail.com, dmitry.torokhov@gmail.com, dtor@mail.ru,
	jgarzik@pobox.com, linux-mm@kvack.org, dwmw2@infradead.org,
	patrick@tykepenguin.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
	jmorris@namei.org, philb@gnu.org, tim@cyberelk.net,
	andrea@suse.de, ambx1@neo.rr.com, James.Bottomley@steeleye.com,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH 00/34] __initdata cleanup
Date: Fri, 9 Feb 2007 18:00:05 +0100	[thread overview]
Message-ID: <20070209170005.GA8500@osiris.ibm.com> (raw)
In-Reply-To: <200702091711.34441.alon.barlev@gmail.com>

On Fri, Feb 09, 2007 at 05:11:32PM +0200, Alon Bar-Lev wrote:
>  
> Follow-up Russell King comment at http://lkml.org/lkml/2007/1/22/267
>
> All __initdata variables should be initialized so they won't end up
> in BSS.
>  
> There is no dependency between patches or even hunks.
>  
> Some architecture patches are untested, this is documented as "UNTESTED"
>  
> Against 2.6.20-rc6-mm3.

To quote parts of that:

Anyway, here's what the GCC manual has to say about use of
__attribute__((section)) on variables:

`section ("SECTION-NAME")'
     Use the `section' attribute with an _initialized_ definition of a
     _global_ variable, as shown in the example.  GCC issues a warning
     and otherwise ignores the `section' attribute in uninitialized
     variable declarations.

     You may only use the `section' attribute with a fully initialized
     global definition because of the way linkers work.  The linker
     requires each object be defined once, with the exception that
     uninitialized variables tentatively go in the `common' (or `bss')
     section and can be multiply "defined".  You can force a variable
     to be initialized with the `-fno-common' flag or the `nocommon'
     attribute.

And the top-level Makefile has:

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common

Note the -fno-common.

And indeed all the __initdata annotated local and global variables on
s390 are in the init.data section. So I'm wondering what this patch
series is about. Or I must have missed something.

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Alon Bar-Lev <alon.barlev@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, bwalle@suse.de,
	rmk+lkml@arm.linux.org.uk, spyro@f2s.com,
	davej@codemonkey.org.uk, hpa@zytor.com, Riley@williams.name,
	tony.luck@intel.com, geert@linux-m68k.org, zippel@linux-m68k.org,
	ralf@linux-mips.org, matthew@wil.cx, grundler@parisc-linux.org,
	kyle@parisc-linux.org, paulus@samba.org, schwidefsky@de.ibm.com,
	lethal@linux-sh.org, davem@davemloft.net,
	uclinux-v850@lsi.nec.co.jp, ak@muc.de, vojtech@suse.cz,
	chris@zankel.net, len.brown@intel.com, lenb@kernel.org,
	herbert@gondor.apana.org.au, viro@zeniv.linux.org.uk,
	bzolnier@gmail.com, dmitry.torokhov@gmail.com, dtor@mail.ru,
	jgarzik@pobox.com, linux-mm@kvack.org, dwmw2@infradead.org,
	patrick@tykepenguin.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
	jmorris@namei.org, philb@gnu.org, tim@cyberelk.net,
	andrea@suse.de, ambx1@neo.rr.com, James.Bottomley@steeleye.com,
	linux-serial
Subject: Re: [PATCH 00/34] __initdata cleanup
Date: Fri, 9 Feb 2007 18:00:05 +0100	[thread overview]
Message-ID: <20070209170005.GA8500@osiris.ibm.com> (raw)
In-Reply-To: <200702091711.34441.alon.barlev@gmail.com>

On Fri, Feb 09, 2007 at 05:11:32PM +0200, Alon Bar-Lev wrote:
>  
> Follow-up Russell King comment at http://lkml.org/lkml/2007/1/22/267
>
> All __initdata variables should be initialized so they won't end up
> in BSS.
>  
> There is no dependency between patches or even hunks.
>  
> Some architecture patches are untested, this is documented as "UNTESTED"
>  
> Against 2.6.20-rc6-mm3.

To quote parts of that:

Anyway, here's what the GCC manual has to say about use of
__attribute__((section)) on variables:

`section ("SECTION-NAME")'
     Use the `section' attribute with an _initialized_ definition of a
     _global_ variable, as shown in the example.  GCC issues a warning
     and otherwise ignores the `section' attribute in uninitialized
     variable declarations.

     You may only use the `section' attribute with a fully initialized
     global definition because of the way linkers work.  The linker
     requires each object be defined once, with the exception that
     uninitialized variables tentatively go in the `common' (or `bss')
     section and can be multiply "defined".  You can force a variable
     to be initialized with the `-fno-common' flag or the `nocommon'
     attribute.

And the top-level Makefile has:

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common

Note the -fno-common.

And indeed all the __initdata annotated local and global variables on
s390 are in the init.data section. So I'm wondering what this patch
series is about. Or I must have missed something.

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Alon Bar-Lev <alon.barlev@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, bwalle@suse.de,
	rmk+lkml@arm.linux.org.uk, spyro@f2s.com,
	davej@codemonkey.org.uk, hpa@zytor.com, Riley@williams.name,
	tony.luck@intel.com, geert@linux-m68k.org, zippel@linux-m68k.org,
	ralf@linux-mips.org, matthew@wil.cx, grundler@parisc-linux.org,
	kyle@parisc-linux.org, paulus@samba.org, schwidefsky@de.ibm.com,
	lethal@linux-sh.org, davem@davemloft.net,
	uclinux-v850@lsi.nec.co.jp, ak@muc.de, vojtech@suse.cz,
	chris@zankel.net, len.brown@intel.com, lenb@kernel.org,
	herbert@gondor.apana.org.au, viro@zeniv.linux.org.uk,
	bzolnier@gmail.com, dmitry.torokhov@gmail.com, dtor@mail.ru,
	jgarzik@pobox.com, linux-mm@kvack.org, dwmw2@infradead.org,
	patrick@tykepenguin.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
	jmorris@namei.org, philb@gnu.org, tim@cyberelk.net,
	andrea@suse.de, ambx1@neo.rr.com, James.Bottomley@steeleye.com,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH 00/34] __initdata cleanup
Date: Fri, 9 Feb 2007 18:00:05 +0100	[thread overview]
Message-ID: <20070209170005.GA8500@osiris.ibm.com> (raw)
In-Reply-To: <200702091711.34441.alon.barlev@gmail.com>

On Fri, Feb 09, 2007 at 05:11:32PM +0200, Alon Bar-Lev wrote:
>  
> Follow-up Russell King comment at http://lkml.org/lkml/2007/1/22/267
>
> All __initdata variables should be initialized so they won't end up
> in BSS.
>  
> There is no dependency between patches or even hunks.
>  
> Some architecture patches are untested, this is documented as "UNTESTED"
>  
> Against 2.6.20-rc6-mm3.

To quote parts of that:

Anyway, here's what the GCC manual has to say about use of
__attribute__((section)) on variables:

`section ("SECTION-NAME")'
     Use the `section' attribute with an _initialized_ definition of a
     _global_ variable, as shown in the example.  GCC issues a warning
     and otherwise ignores the `section' attribute in uninitialized
     variable declarations.

     You may only use the `section' attribute with a fully initialized
     global definition because of the way linkers work.  The linker
     requires each object be defined once, with the exception that
     uninitialized variables tentatively go in the `common' (or `bss')
     section and can be multiply "defined".  You can force a variable
     to be initialized with the `-fno-common' flag or the `nocommon'
     attribute.

And the top-level Makefile has:

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common

Note the -fno-common.

And indeed all the __initdata annotated local and global variables on
s390 are in the init.data section. So I'm wondering what this patch
series is about. Or I must have missed something.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2007-02-09 17:01 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-09 15:11 [PATCH 00/34] __initdata cleanup Alon Bar-Lev
2007-02-09 15:13 ` [PATCH 01/34] __initdata cleanup - alpha Alon Bar-Lev
2007-02-09 16:47   ` Jiri Slaby
2007-02-09 16:52     ` Alon Bar-Lev
2007-02-09 17:11       ` Jiri Slaby
2007-02-09 15:13 ` [PATCH 02/34] __initdata cleanup - arm Alon Bar-Lev
2007-02-09 15:14 ` [PATCH 03/34] __initdata cleanup - avr32 Alon Bar-Lev
2007-02-09 15:15 ` [PATCH 04/34] __initdata cleanup - frv Alon Bar-Lev
2007-02-09 15:15 ` [PATCH 05/34] __initdata cleanup - h8300 Alon Bar-Lev
2007-02-09 15:16 ` [PATCH 06/34] __initdata cleanup - i386 Alon Bar-Lev
2007-02-09 15:17 ` [PATCH 07/34] __initdata cleanup - ia64 Alon Bar-Lev
2007-02-09 15:18 ` [PATCH 08/34] __initdata cleanup - m32r Alon Bar-Lev
2007-02-09 15:19 ` [PATCH 09/34] __initdata cleanup - m68knommu Alon Bar-Lev
2007-02-09 15:19 ` [PATCH 10/34] __initdata cleanup - mips Alon Bar-Lev
2007-02-09 15:20 ` [PATCH 11/34] __initdata cleanup - parisc Alon Bar-Lev
2007-02-09 15:21 ` [PATCH 12/34] __initdata cleanup - powerpc Alon Bar-Lev
2007-02-09 15:21 ` [PATCH 13/34] __initdata cleanup - ppc Alon Bar-Lev
2007-02-09 15:22 ` [PATCH 14/34] __initdata cleanup - s390 Alon Bar-Lev
2007-02-09 15:22 ` [PATCH 15/34] __initdata cleanup - sh Alon Bar-Lev
2007-02-09 15:23 ` [PATCH 16/34] __initdata cleanup - sparc64 Alon Bar-Lev
2007-02-09 15:23 ` [PATCH 17/34] __initdata cleanup - v850 Alon Bar-Lev
2007-02-09 15:24 ` [PATCH 18/34] __initdata cleanup - x86_64 Alon Bar-Lev
2007-02-09 19:35   ` Andi Kleen
2007-02-09 19:45     ` Bernhard Walle
2007-02-09 15:24 ` [PATCH 19/34] __initdata cleanup - xtensa Alon Bar-Lev
2007-02-09 15:25 ` [PATCH 20/34] __initdata cleanup - acpi Alon Bar-Lev
2007-02-09 15:25 ` [PATCH 21/34] __initdata cleanup - aes Alon Bar-Lev
2007-02-09 15:26 ` [PATCH 22/34] __initdata cleanup - fs Alon Bar-Lev
2007-02-09 15:27 ` [PATCH 23/34] __initdata cleanup - ide Alon Bar-Lev
2007-02-09 15:28 ` [PATCH 24/34] __initdata cleanup - init Alon Bar-Lev
2007-02-09 15:30 ` [PATCH 25/34] __initdata cleanup - input Alon Bar-Lev
2007-02-09 15:31 ` [PATCH 26/34] __initdata cleanup - intel-rng Alon Bar-Lev
2007-02-09 15:31 ` [PATCH 27/34] __initdata cleanup - mm Alon Bar-Lev
2007-02-09 15:31   ` Alon Bar-Lev
2007-02-09 15:32 ` [PATCH 28/34] __initdata cleanup - mtd Alon Bar-Lev
2007-02-09 15:33 ` [PATCH 29/34] __initdata cleanup - net Alon Bar-Lev
2007-02-09 15:33 ` [PATCH 30/34] __initdata cleanup - parallel Alon Bar-Lev
2007-02-09 15:34 ` [PATCH 31/34] __initdata cleanup - pnp Alon Bar-Lev
2007-02-09 15:34 ` [PATCH 32/34] __initdata cleanup - scsi Alon Bar-Lev
2007-02-09 15:35 ` [PATCH 33/34] __initdata cleanup - serial Alon Bar-Lev
2007-02-09 15:35 ` [PATCH 34/34] __initdata cleanup - video Alon Bar-Lev
2007-02-09 17:00 ` Heiko Carstens [this message]
2007-02-09 17:00   ` [PATCH 00/34] __initdata cleanup Heiko Carstens
2007-02-09 17:00   ` Heiko Carstens
2007-02-09 17:25   ` Alon Bar-Lev
2007-02-09 17:25     ` Alon Bar-Lev
2007-02-09 17:25     ` Alon Bar-Lev
2007-02-09 17:37   ` Roman Zippel
2007-02-09 17:37     ` Roman Zippel
2007-02-09 17:37     ` Roman Zippel
2007-02-09 21:33     ` Andrew Morton
2007-02-09 21:33       ` Andrew Morton
2007-02-09 21:33       ` Andrew Morton
2007-02-09 21:48       ` Alon Bar-Lev
2007-02-09 22:11         ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070209170005.GA8500@osiris.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=Riley@williams.name \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=alon.barlev@gmail.com \
    --cc=ambx1@neo.rr.com \
    --cc=andrea@suse.de \
    --cc=bwalle@suse.de \
    --cc=bzolnier@gmail.com \
    --cc=chris@zankel.net \
    --cc=davej@codemonkey.org.uk \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dtor@mail.ru \
    --cc=dwmw2@infradead.org \
    --cc=geert@linux-m68k.org \
    --cc=grundler@parisc-linux.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jgarzik@pobox.com \
    --cc=jmorris@namei.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=kyle@parisc-linux.org \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=patrick@tykepenguin.com \
    --cc=paulus@samba.org \
    --cc=pekkas@netcore.fi \
    --cc=philb@gnu.org \
    --cc=ralf@linux-mips.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=schwidefsky@de.ibm.com \
    --cc=spyro@f2s.com \
    --cc=tim@cyberelk.net \
    --cc=tony.luck@intel.com \
    --cc=uclinux-v850@lsi.nec.co.jp \
    --cc=viro@zeniv.linux.org.uk \
    --cc=vojtech@suse.cz \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.