All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Jean Delvare <khali@linux-fr.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Questions on __initdata
Date: Tue, 06 Dec 2005 15:42:46 +1100	[thread overview]
Message-ID: <9121.1133844166@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Sun, 04 Dec 2005 15:15:33 BST." <20051204151533.13df37c6.khali@linux-fr.org>

On Sun, 4 Dec 2005 15:15:33 +0100, 
Jean Delvare <khali@linux-fr.org> wrote:
>Hi all,
>
>I've been reading the heading comment of include/linux/init.h to learn
>when and how __initdata can be used. Some of the help text doesn't seem
>to match my observations, and some of it confused me and could probably
>be made clearer. However, I don't feel completely comfortable with this
>topic yet and would welcome comments.
>
>First, the comment goes:
>
>> /* These macros are used to mark some functions or 
>>  * initialized data (doesn't apply to uninitialized data)
>>  * as `initialization' functions. The kernel can take this
>>  * as hint that the function is used only during the initialization
>>  * phase and free up used memory resources after
>
>My tests (on i386) seem to suggest that "doesn't apply to uninitialized
>data" only holds for non-global variables. Tagging uninitialized global
>variables __initdata works, and moves the variables from .bss to .data.
>Is it correct? Does it work on all archs? If so, the comment above
>needs to be fixed.

gcc version dependent.  Older versions of gcc put all uninitialized
global variables into .bss, even if there was an attribute like
__initdata that tried to use a different section.  So we got into the
habit of '__initdata variables must be explicitly initialized'.  Some
platforms are using old versions of gcc where that restriction may
still apply.


      parent reply	other threads:[~2005-12-06  4:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-04 14:15 Questions on __initdata Jean Delvare
2005-12-04 16:41 ` Arnd Bergmann
2005-12-05 20:37   ` Ralf Baechle
2005-12-06 13:32     ` Paweł Sikora
2005-12-06 13:48       ` Ralf Baechle
2005-12-06  4:42 ` Keith Owens [this message]

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=9121.1133844166@kao2.melbourne.sgi.com \
    --to=kaos@ocs.com.au \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.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.