lkml.org 
[lkml]   [2009]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] also discard .*init sections after module initialization
On Wed, 1 Jul 2009, Jan Beulich wrote:

> >>> Rusty Russell <rusty@rustcorp.com.au> 01.07.09 07:22 >>>
> >On Tue, 30 Jun 2009 09:27:26 pm Jan Beulich wrote:
> >> Just like .init, these sections are supposed to be unneeded after init,
> >> and modpost warns about improper section references anyway.
> >
> >Tim Abbot had a section renaming patch, for -ffunction-sections. Can we kill
> >two birds with one stone and have a unique string for init sections, and
> >another for exit sections?
>
> Not sure, would need to see what that patch does first. And then, the patch
> here doesn't do any renaming.

We don't need to rename the .{dev,cpu,mem}init.* sections for
-ffunction-sections -fdata-sections; the only things that need to be
renamed for that are sections with names that start with ".text.",
".data.", ".bss.", and ".rodata." since those are the section names
generated by -ffunction-sections -fdata-sections. So I think that this
change is orthogonal to my efforts.

> >> Likewise
> >> for .*exit which, other than .exit, aren't needed for the module unload
> >> path.
> >
> >Currently true, but I can't see that being true in general.
>
> Why? .*exit sections deal with device/memory/CPU hot remove, which is
> orthogonal to module unload.

For the core kernel, the .devinit sections are currently being squashed
into either the .data section or the .init.data section depending on
whether hotplug is enabled using the vmlinux linker scripts. Can we use
the same approach for modules (i.e. have a module linker script that does
this)? It seems that would avoid having two duplicate mechanisms for
doing the same thing, one in the module loader and one in the core
kernel's linker scripts.

-Tim Abbott




\
 
 \ /
  Last update: 2009-07-06 17:59    [W:0.041 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site