From: Matt Mackall <mpm@selenic.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: Joe Perches <joe@perches.com>,
linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Gortmaker <paul.gortmaker@windriver.com>,
David Woodhouse <dwmw2@infradead.org>,
Tim Bird <tim.bird@am.sony.com>
Subject: Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
Date: Tue, 21 Jul 2009 20:28:05 -0500 [thread overview]
Message-ID: <1248226085.10466.251.camel@calx> (raw)
In-Reply-To: <4A665442.1010006@caviumnetworks.com>
On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote:
> Joe Perches wrote:
> > On Tue, 2009-07-21 at 17:57 -0500, Matt Mackall wrote:
> >> On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
> >>> On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
> >>>> On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
> >>>>> Is moving constant string formats to __devinitconst or __initdata
> >>>>> useful for embedded environments?
> >>>> Interesting notion, but not worth the trouble in my mind. I think it's
> >>>> more worthwhile to look into automatic such stuff in the build somehow.
> >>> I think it's not possible today to get gcc to mark
> >>> the format strings without source modification.
> >> Yep, that's why I specifically said 'build'. It can probably be done in
> >> a post-processing step with some ELF wizardry.
> >
> > Know any elven wizards?
> >
>
> It would be tricky, the string data from the entire compilation unit is
> intermingled. You would have to separate out only those strings
> referenced from __init sections into their own section and fix up all
> symbols and relocations that were affected.
Exactly. Annoying but not impossible.
> Probably easier would be to use the plug-in feature that will be part of
> GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux
> kernel GCC plug-in that just emits the __init literal strings to the
> proper section to begin with. This wouldn't be unprecedented, the
> Mozilla people already use their own extensions to GCC, and will
> probably migrate to GCC plug-ins. We don't want the kernel to get left
> behind in the GCC plug-in race.
There are no doubt a number of things we could be doing with such
extensions.
--
http://selenic.com : development and support for Mercurial and Linux
next prev parent reply other threads:[~2009-07-22 1:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-21 21:20 [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata? Joe Perches
2009-07-21 21:48 ` Matt Mackall
2009-07-21 21:56 ` Joe Perches
2009-07-21 22:57 ` Matt Mackall
2009-07-21 23:05 ` Joe Perches
2009-07-21 23:50 ` David Daney
2009-07-22 1:28 ` Matt Mackall [this message]
2009-07-22 4:50 ` Joe Perches
2009-07-22 5:17 ` Matt Mackall
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=1248226085.10466.251.camel@calx \
--to=mpm@selenic.com \
--cc=ddaney@caviumnetworks.com \
--cc=dwmw2@infradead.org \
--cc=joe@perches.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=tim.bird@am.sony.com \
/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.