From: Matt Mackall <mpm@selenic.com>
To: Joe Perches <joe@perches.com>
Cc: David Daney <ddaney@caviumnetworks.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: Wed, 22 Jul 2009 00:17:30 -0500 [thread overview]
Message-ID: <1248239850.10466.277.camel@calx> (raw)
In-Reply-To: <1248238202.31365.576.camel@Joe-Laptop.home>
On Tue, 2009-07-21 at 21:50 -0700, Joe Perches wrote:
> On Tue, 2009-07-21 at 20:28 -0500, Matt Mackall wrote:
> > On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote:
> > > 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.
>
> But faster and likely easier to do once in source.
How long have you been hanging out here, Joe? You really thing it's
going to be EASY to push this change to literally thousands of drivers?
Your idea may work but it isn't pretty and also isn't an obvious big win
and is therefore going to hit a lot of friction from lots of different
people. It's already getting friction from me and I actually care about
this sort of thing.
That effort would be better spent working on something transparent,
automatic, and painless. Something people won't put up a fight about.
> > > 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.
>
> Which is what the proposed marking would
> more or less do today.
>
> > > We don't want the kernel to get left
> > > behind in the GCC plug-in race.
>
> Any guess when gcc 4.5/5.0 might become available?
> It's in stage 1 now. Mid 2010 or so?
>
> 4.4.0 was April 21, 2009
> 4.3.0 was March 5, 2008
> 4.2.0 was May 13, 2007
>
> Could you please send me what you think is a
> reasonable .config for an embedded box.
Lots of devices have only MTD, JFFS, ethernet, and one other driver like
wifi.
--
http://selenic.com : development and support for Mercurial and Linux
prev parent reply other threads:[~2009-07-22 5:17 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
2009-07-22 4:50 ` Joe Perches
2009-07-22 5:17 ` Matt Mackall [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=1248239850.10466.277.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).