[PATCH 1/2] Allow constructor name selection by architecture.
Vincent Sanders
vincent.sanders at collabora.co.uk
Tue May 29 05:21:20 EDT 2012
On Mon, May 28, 2012 at 10:30:05PM +0200, Sam Ravnborg wrote:
> On Mon, May 28, 2012 at 07:33:37PM +0100, Vincent Sanders wrote:
> > From: Vincent Sanders <vince at collabora.co.uk>
> >
> > The constructor symbol name is different between platforms. Allow this
> > to be selected by configuration and set suitable default values.
> >
> > Signed-off-by: Vincent Sanders <vincent.sanders at collabora.co.uk>
> > ---
> > include/asm-generic/vmlinux.lds.h | 6 +++---
> > init/Kconfig | 6 ++++++
> > kernel/module.c | 2 +-
> > 3 files changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 8aeadf6..fd34808 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -471,9 +471,9 @@
> > }
> >
> > #ifdef CONFIG_CONSTRUCTORS
> > -#define KERNEL_CTORS() . = ALIGN(8); \
> > - VMLINUX_SYMBOL(__ctors_start) = .; \
> > - *(.ctors) \
> > +#define KERNEL_CTORS() . = ALIGN(8); \
> > + VMLINUX_SYMBOL(__ctors_start) = .; \
> > + *(CONFIG_CONSTRUCTORS_NAME) \
> > VMLINUX_SYMBOL(__ctors_end) = .;
>
> What is wrong with adding both "standard" names for ctors uncnditionally?
> Like this:
> > *(.ctors) \
> > + *(.init_array) \
>
Persoinally I have no strong opinion and would alter approach.
As I understand it the previous objections to the "put them all in"
approach (this change has been round the loop before) were:
- It contaminates the x86 symbol namespace and if init_array was used on
not ARM it might lead to surprises
- If another architecture needs something different again then we are
going to end up with another symbol.
- The module loading code has to be changed to allow either symbol.
The only technical issue really is the module symbol handling and I am
unsure how to robustly handle that.
--
Regards Vincent
http://www.kyllikki.org/
More information about the linux-arm-kernel
mailing list