lkml.org 
[lkml]   [2008]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] __cpuinitconst and __devinitconst
Hi Jan.

On Fri, Jan 11, 2008 at 08:55:29AM +0000, Jan Beulich wrote:
> Since __cpuinitdata/__devinitdata don't allow const to be specified with
> them (otherwise .init.data sections with and without the writeable attribute
> will be generated by the compiler), and since __devinitdata except for
> embedded systems evaluates to <empty> unconditionally and
> __cpuinitdata at least in most production kernel configurations also
> likely evaluates to <empty>, it seems appropriate to add an additional
> attribute allowing the respective objects to end up in .rodata rather than
> .data when not used at initialization time only.

How about a slightly diffrent approach...
Consider
__cpuinitconst => function is placed in section .init.const.text
__devinitconst => function is placed in section .init.const.text

Then we in the linker scrip can distingush between the two
and locate the sections as appropriate.

This will require some updates to modpost but are align with an
idea I have had for a while.
All of the following should have dedicated sections associated
unconditionally:

__init
__cpuinit
__meminit
__initdata
__cpuinitdata
__meminitdata

And then in the linker script we decide what to do with the section.
In the built-in case we put them in the "to-be-discarded" section.
In the module case we put them as today.

The primary tasks needed to accomplish this is:
1) Update all arch linker scripts (and some of them looks ugly)
2) Teach modpost about the new sections

If you following the suggestion above this is a simple step
in this direction which would be good.

Comments?

Sam


\
 
 \ /
  Last update: 2008-01-11 20:47    [W:0.039 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site