Is moving constant string formats to __devinitconst or __initdata
useful for embedded environments?
As in:
#define printk_section(section, fmt, ...) \
({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
#define pr_err_section(section, fmt, ...) \
printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
with a use of:
static int __devinit foo_probe(struct platform_device *pdev)
{
if (bar())
pr_err_section(__devinitconst,
"A long error message\n");
}
or
static int __init foo_init(struct platform_device *pdev)
{
if (bar())
pr_err_section(__initdata,
"A long error message\n");
}
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?
>
> As in:
>
> #define printk_section(section, fmt, ...) \
> ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
>
> #define pr_err_section(section, fmt, ...) \
> printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
>
> with a use of:
>
> static int __devinit foo_probe(struct platform_device *pdev)
> {
> if (bar())
> pr_err_section(__devinitconst,
> "A long error message\n");
> }
>
> or
>
> static int __init foo_init(struct platform_device *pdev)
> {
> if (bar())
> pr_err_section(__initdata,
> "A long error message\n");
> }
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.
--
http://selenic.com : development and support for Mercurial and Linux
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?
> > As in:
> > #define printk_section(section, fmt, ...) \
> > ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
> > #define pr_err_section(section, fmt, ...) \
> > printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> > with a use of:
> > static int __devinit foo_probe(struct platform_device *pdev)
> > {
> > if (bar())
> > pr_err_section(__devinitconst,
> > "A long error message\n");
> > }
> 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.
It's pretty easy to script a source conversion.
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?
> > > As in:
> > > #define printk_section(section, fmt, ...) \
> > > ({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__); })
> > > #define pr_err_section(section, fmt, ...) \
> > > printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
> > > with a use of:
> > > static int __devinit foo_probe(struct platform_device *pdev)
> > > {
> > > if (bar())
> > > pr_err_section(__devinitconst,
> > > "A long error message\n");
> > > }
>
> > 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.
> It's pretty easy to script a source conversion.
And that script has to be run how often? I don't think people will find
the churn (and general extra ugliness) acceptable. For a typical
stripped-down embedded kernel, the amount of gain here will be fairly
minimal. I'd be surprised if you got as much as 1K out of it.
--
http://selenic.com : development and support for Mercurial and Linux
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's pretty easy to script a source conversion.
>
> And that script has to be run how often?
Once.
> I don't think people will find
> the churn (and general extra ugliness) acceptable. For a typical
> stripped-down embedded kernel, the amount of gain here will be fairly
> minimal. I'd be surprised if you got as much as 1K out of it.
Got a typical config that uses printks I could try?
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.
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.
David Daney
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
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.
> > 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.
cheers, Joe
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