Messages in this thread | | | Date | Fri, 11 Jan 2008 20:44:28 +0100 | From | Sam Ravnborg <> | Subject | Re: [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
| |