Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Mon, Jan 14, 2008 at 09:25:54AM +, Jan Beulich wrote:
> >> The one thing that I'm not sure is really consistent yet wrt. the
> >> constification is that now you need to write e.g.
> >>
> >> static const char __cpuinitcdata example[];
> >>
> >> and (accidentally) omitting the 'const' (as it's really an apparently
> >> redundant thing now) as in
> >>
> >> static char __cpuinitcdata example[];
> >>
> >> will cause section type conflicts (at the compiler or linker level). I
> >> therefore think that the 'const' should really be part of the
> >> __{cpu,mem,dev}cdata definitions (requiring the attribute to be
> >> placed properly, namely placement at the end of a declaration as
> >> is possible with __{cpu,mem,dev}initdata is then not an option here).
> >
> >I need to play a little with this before I make up my mind.
> >I do not like the concpet of hiding the const too much - it will
> >be non-obvious why the compiler complains if the only thing that
> >distingush const from non-const is a small capital 'c' within
> >__cpucinitdata (versus __cpuinitdata).
>
> That's the main reason I preferred __{cpu,mem,dev}initconst, as it
> makes it more obvious that the declared thing is 'const'.
I will try with these names - thanks (Saw Adrian's comment but
agree it is too long).
I will likely not have anything ready until wednesday so feel
free to beat me.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
>> The one thing that I'm not sure is really consistent yet wrt. the
>> constification is that now you need to write e.g.
>>
>> static const char __cpuinitcdata example[];
>>
>> and (accidentally) omitting the 'const' (as it's really an apparently
>> redundant thing now) as in
>>
>> static char __cpuinitcdata example[];
>>
>> will cause section type conflicts (at the compiler or linker level). I
>> therefore think that the 'const' should really be part of the
>> __{cpu,mem,dev}cdata definitions (requiring the attribute to be
>> placed properly, namely placement at the end of a declaration as
>> is possible with __{cpu,mem,dev}initdata is then not an option here).
>
>I need to play a little with this before I make up my mind.
>I do not like the concpet of hiding the const too much - it will
>be non-obvious why the compiler complains if the only thing that
>distingush const from non-const is a small capital 'c' within
>__cpucinitdata (versus __cpuinitdata).
That's the main reason I preferred __{cpu,mem,dev}initconst, as it
makes it more obvious that the declared thing is 'const'.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Mon, Jan 14, 2008 at 08:33:35AM +, Jan Beulich wrote:
> >>> Sam Ravnborg <[EMAIL PROTECTED]> 13.01.08 22:42 >>>
> >> And I found another small buglet too. I hope to post a complete
> >> solution later today.
> >
> >The modpost bits turned out to take longer than expected so
> >they are not done yet. The problem was the modpost structure
> >were not prepared for adding such additional chacks.
> >So I reworked those bits and the patch has been sent out for review.
> >
> >What follows here is the changes for init.h + all linker scripts
> >to show the idea.
> >
> >Next step is to beat modpost in shape and to post this on linux-arch.
> >
> >Note - in -mm there are changes to init.h so the logic
> >to decide type of __meminit notation is much simpler.
>
> Yes, I certainly like this concept. What I would have wanted in that patch,
> though, is that the read-only data would right away be included in
> RODATA() rather than being put in DATA_DATA.
Will fix that in next patch. My focus was on the concept when I did the
patch but it is dead easy to fix for ll archs at once.
> Also, to shorten the
> names a little, how about .{cpu,mem,dev}init.rodata?
Good suggestion - will use these.
> The one thing that I'm not sure is really consistent yet wrt. the
> constification is that now you need to write e.g.
>
> static const char __cpuinitcdata example[];
>
> and (accidentally) omitting the 'const' (as it's really an apparently
> redundant thing now) as in
>
> static char __cpuinitcdata example[];
>
> will cause section type conflicts (at the compiler or linker level). I
> therefore think that the 'const' should really be part of the
> __{cpu,mem,dev}cdata definitions (requiring the attribute to be
> placed properly, namely placement at the end of a declaration as
> is possible with __{cpu,mem,dev}initdata is then not an option here).
I need to play a little with this before I make up my mind.
I do not like the concpet of hiding the const too much - it will
be non-obvious why the compiler complains if the only thing that
distingush const from non-const is a small capital 'c' within
__cpucinitdata (versus __cpuinitdata).
It can always be an incremental patch as my concpet does not prevent
it and we have only a few const __initdata variables.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
>>> Sam Ravnborg <[EMAIL PROTECTED]> 13.01.08 22:42 >>>
>> And I found another small buglet too. I hope to post a complete
>> solution later today.
>
>The modpost bits turned out to take longer than expected so
>they are not done yet. The problem was the modpost structure
>were not prepared for adding such additional chacks.
>So I reworked those bits and the patch has been sent out for review.
>
>What follows here is the changes for init.h + all linker scripts
>to show the idea.
>
>Next step is to beat modpost in shape and to post this on linux-arch.
>
>Note - in -mm there are changes to init.h so the logic
>to decide type of __meminit notation is much simpler.
Yes, I certainly like this concept. What I would have wanted in that patch,
though, is that the read-only data would right away be included in
RODATA() rather than being put in DATA_DATA. Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata example[];
will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
Sam Ravnborg [EMAIL PROTECTED] 13.01.08 22:42
And I found another small buglet too. I hope to post a complete
solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such additional chacks.
So I reworked those bits and the patch has been sent out for review.
What follows here is the changes for init.h + all linker scripts
to show the idea.
Next step is to beat modpost in shape and to post this on linux-arch.
Note - in -mm there are changes to init.h so the logic
to decide type of __meminit notation is much simpler.
Yes, I certainly like this concept. What I would have wanted in that patch,
though, is that the read-only data would right away be included in
RODATA() rather than being put in DATA_DATA. Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata example[];
will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Mon, Jan 14, 2008 at 08:33:35AM +, Jan Beulich wrote:
Sam Ravnborg [EMAIL PROTECTED] 13.01.08 22:42
And I found another small buglet too. I hope to post a complete
solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such additional chacks.
So I reworked those bits and the patch has been sent out for review.
What follows here is the changes for init.h + all linker scripts
to show the idea.
Next step is to beat modpost in shape and to post this on linux-arch.
Note - in -mm there are changes to init.h so the logic
to decide type of __meminit notation is much simpler.
Yes, I certainly like this concept. What I would have wanted in that patch,
though, is that the read-only data would right away be included in
RODATA() rather than being put in DATA_DATA.
Will fix that in next patch. My focus was on the concept when I did the
patch but it is dead easy to fix for ll archs at once.
Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?
Good suggestion - will use these.
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata example[];
will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).
I need to play a little with this before I make up my mind.
I do not like the concpet of hiding the const too much - it will
be non-obvious why the compiler complains if the only thing that
distingush const from non-const is a small capital 'c' within
__cpucinitdata (versus __cpuinitdata).
It can always be an incremental patch as my concpet does not prevent
it and we have only a few const __initdata variables.
Sam
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata example[];
will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).
I need to play a little with this before I make up my mind.
I do not like the concpet of hiding the const too much - it will
be non-obvious why the compiler complains if the only thing that
distingush const from non-const is a small capital 'c' within
__cpucinitdata (versus __cpuinitdata).
That's the main reason I preferred __{cpu,mem,dev}initconst, as it
makes it more obvious that the declared thing is 'const'.
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Mon, Jan 14, 2008 at 09:25:54AM +, Jan Beulich wrote:
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata example[];
will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).
I need to play a little with this before I make up my mind.
I do not like the concpet of hiding the const too much - it will
be non-obvious why the compiler complains if the only thing that
distingush const from non-const is a small capital 'c' within
__cpucinitdata (versus __cpuinitdata).
That's the main reason I preferred __{cpu,mem,dev}initconst, as it
makes it more obvious that the declared thing is 'const'.
I will try with these names - thanks (Saw Adrian's comment but
agree it is too long).
I will likely not have anything ready until wednesday so feel
free to beat me.
Sam
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
> And I found another small buglet too. I hope to post a complete
> solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such additional chacks.
So I reworked those bits and the patch has been sent out for review.
What follows here is the changes for init.h + all linker scripts
to show the idea.
Next step is to beat modpost in shape and to post this on linux-arch.
Note - in -mm there are changes to init.h so the logic
to decide type of __meminit notation is much simpler.
Sam
arch/alpha/kernel/vmlinux.lds.S |8 +--
arch/arm/kernel/vmlinux.lds.S | 10 ++--
arch/avr32/kernel/vmlinux.lds.S |8 +--
arch/blackfin/kernel/vmlinux.lds.S |8 +--
arch/cris/arch-v10/vmlinux.lds.S|8 +--
arch/cris/arch-v32/vmlinux.lds.S|8 +--
arch/frv/kernel/vmlinux.lds.S | 14 +++---
arch/h8300/kernel/vmlinux.lds.S |8 +--
arch/ia64/kernel/vmlinux.lds.S |8 +--
arch/m32r/kernel/vmlinux.lds.S | 12 ++---
arch/m68k/kernel/vmlinux-std.lds|8 +--
arch/m68k/kernel/vmlinux-sun3.lds |8 +--
arch/m68knommu/kernel/vmlinux.lds.S |8 +--
arch/mips/kernel/vmlinux.lds.S |8 +--
arch/parisc/kernel/vmlinux.lds.S|8 +--
arch/powerpc/kernel/vmlinux.lds.S | 10 ++--
arch/ppc/kernel/vmlinux.lds.S |8 +--
arch/s390/kernel/vmlinux.lds.S |8 +--
arch/sh/kernel/vmlinux.lds.S|8 +--
arch/sh64/kernel/vmlinux.lds.S |8 +--
arch/sparc/kernel/vmlinux.lds.S |8 +--
arch/sparc64/kernel/vmlinux.lds.S |8 +--
arch/um/kernel/dyn.lds.S|4 -
arch/um/kernel/uml.lds.S|4 -
arch/v850/kernel/vmlinux.lds.S | 10 ++--
arch/x86/kernel/vmlinux_32.lds.S| 14 --
arch/x86/kernel/vmlinux_64.lds.S| 19 ++--
arch/xtensa/kernel/vmlinux.lds.S|9 ++--
include/asm-generic/vmlinux.lds.h | 77 +++-
include/linux/init.h| 56 +-
30 files changed, 229 insertions(+), 154 deletions(-)
diff --git a/arch/alpha/kernel/vmlinux.lds.S b/arch/alpha/kernel/vmlinux.lds.S
index 55c05b5..f13249b 100644
--- a/arch/alpha/kernel/vmlinux.lds.S
+++ b/arch/alpha/kernel/vmlinux.lds.S
@@ -46,11 +46,11 @@ SECTIONS
__init_begin = .;
.init.text : {
_sinittext = .;
- *(.init.text)
+ INIT_TEXT
_einittext = .;
}
.init.data : {
- *(.init.data)
+ INIT_DATA
}
. = ALIGN(16);
@@ -136,8 +136,8 @@ SECTIONS
/* Sections to be discarded */
/DISCARD/ : {
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
}
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 5ff5406..52221ef 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -30,7 +30,7 @@ SECTIONS
}
.init : { /* Init code and data */
- *(.init.text)
+ INIT_TEXT
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
@@ -70,15 +70,15 @@ SECTIONS
__per_cpu_end = .;
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
}
/DISCARD/ : { /* Exit code and data */
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
#ifndef CONFIG_MMU
*(.fixup)
@@ -129,7 +129,7 @@ SECTIONS
#ifdef CONFIG_XIP_KERNEL
. = ALIGN(4096);
__init_begin = .;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
diff --git a/arch/avr32/kernel/vmlinux.lds.S b/arch/avr32/kernel/vmlinux.lds.S
index 11f08e3..481cfd4 100644
--- a/arch/avr32/kernel/vmlinux.lds.S
+++ b/arch/avr32/kernel/vmlinux.lds.S
@@ -27,19 +27,19 @@ SECTIONS
__init_begin = .;
_sinittext = .;
*(.text.reset)
- *(.init.text)
+ INIT_TEXT
/*
* .exit.text is discarded at runtime, not
* link time, to deal with references from
* __bug_table
*/
- *(.exit.text)
+ EXIT_TEXT
_einittext = .;
. = ALIGN(4);
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
And I found another small buglet too. I hope to post a complete
solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such additional chacks.
So I reworked those bits and the patch has been sent out for review.
What follows here is the changes for init.h + all linker scripts
to show the idea.
Next step is to beat modpost in shape and to post this on linux-arch.
Note - in -mm there are changes to init.h so the logic
to decide type of __meminit notation is much simpler.
Sam
arch/alpha/kernel/vmlinux.lds.S |8 +--
arch/arm/kernel/vmlinux.lds.S | 10 ++--
arch/avr32/kernel/vmlinux.lds.S |8 +--
arch/blackfin/kernel/vmlinux.lds.S |8 +--
arch/cris/arch-v10/vmlinux.lds.S|8 +--
arch/cris/arch-v32/vmlinux.lds.S|8 +--
arch/frv/kernel/vmlinux.lds.S | 14 +++---
arch/h8300/kernel/vmlinux.lds.S |8 +--
arch/ia64/kernel/vmlinux.lds.S |8 +--
arch/m32r/kernel/vmlinux.lds.S | 12 ++---
arch/m68k/kernel/vmlinux-std.lds|8 +--
arch/m68k/kernel/vmlinux-sun3.lds |8 +--
arch/m68knommu/kernel/vmlinux.lds.S |8 +--
arch/mips/kernel/vmlinux.lds.S |8 +--
arch/parisc/kernel/vmlinux.lds.S|8 +--
arch/powerpc/kernel/vmlinux.lds.S | 10 ++--
arch/ppc/kernel/vmlinux.lds.S |8 +--
arch/s390/kernel/vmlinux.lds.S |8 +--
arch/sh/kernel/vmlinux.lds.S|8 +--
arch/sh64/kernel/vmlinux.lds.S |8 +--
arch/sparc/kernel/vmlinux.lds.S |8 +--
arch/sparc64/kernel/vmlinux.lds.S |8 +--
arch/um/kernel/dyn.lds.S|4 -
arch/um/kernel/uml.lds.S|4 -
arch/v850/kernel/vmlinux.lds.S | 10 ++--
arch/x86/kernel/vmlinux_32.lds.S| 14 --
arch/x86/kernel/vmlinux_64.lds.S| 19 ++--
arch/xtensa/kernel/vmlinux.lds.S|9 ++--
include/asm-generic/vmlinux.lds.h | 77 +++-
include/linux/init.h| 56 +-
30 files changed, 229 insertions(+), 154 deletions(-)
diff --git a/arch/alpha/kernel/vmlinux.lds.S b/arch/alpha/kernel/vmlinux.lds.S
index 55c05b5..f13249b 100644
--- a/arch/alpha/kernel/vmlinux.lds.S
+++ b/arch/alpha/kernel/vmlinux.lds.S
@@ -46,11 +46,11 @@ SECTIONS
__init_begin = .;
.init.text : {
_sinittext = .;
- *(.init.text)
+ INIT_TEXT
_einittext = .;
}
.init.data : {
- *(.init.data)
+ INIT_DATA
}
. = ALIGN(16);
@@ -136,8 +136,8 @@ SECTIONS
/* Sections to be discarded */
/DISCARD/ : {
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
}
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 5ff5406..52221ef 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -30,7 +30,7 @@ SECTIONS
}
.init : { /* Init code and data */
- *(.init.text)
+ INIT_TEXT
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
@@ -70,15 +70,15 @@ SECTIONS
__per_cpu_end = .;
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
}
/DISCARD/ : { /* Exit code and data */
- *(.exit.text)
- *(.exit.data)
+ EXIT_TEXT
+ EXIT_DATA
*(.exitcall.exit)
#ifndef CONFIG_MMU
*(.fixup)
@@ -129,7 +129,7 @@ SECTIONS
#ifdef CONFIG_XIP_KERNEL
. = ALIGN(4096);
__init_begin = .;
- *(.init.data)
+ INIT_DATA
. = ALIGN(4096);
__init_end = .;
#endif
diff --git a/arch/avr32/kernel/vmlinux.lds.S b/arch/avr32/kernel/vmlinux.lds.S
index 11f08e3..481cfd4 100644
--- a/arch/avr32/kernel/vmlinux.lds.S
+++ b/arch/avr32/kernel/vmlinux.lds.S
@@ -27,19 +27,19 @@ SECTIONS
__init_begin = .;
_sinittext = .;
*(.text.reset)
- *(.init.text)
+ INIT_TEXT
/*
* .exit.text is discarded at runtime, not
* link time, to deal with references from
* __bug_table
*/
- *(.exit.text)
+ EXIT_TEXT
_einittext = .;
. = ALIGN(4);
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
> > +#ifdef CONFIG_HOTPLUG > +#define DEV_KEEP(sec) > +#define DEV_DISCARD(sec) *(.dev##sec) > +#else > +#define DEV_KEEP(sec)*(.dev##sec) > +#define DEV_DISCARD(sec) > +#endif > + > +#ifdef CONFIG_HOTPLUG_CPU > +#define CPU_KEEP(sec) > +#define CPU_DISCARD(sec) *(.cpu##sec) > +#else > +#define CPU_KEEP(sec)*(.cpu##sec) > +#define CPU_DISCARD(sec) > +#endif > + > +#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \ > +|| defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE) > +#define MEM_KEEP(sec) > +#define MEM_DISCARD(sec) *(.mem##sec) > +#else > +#define MEM_KEEP(sec)*(.mem##sec) > +#define MEM_DISCARD(sec) > +#endif I inversed it in the ifdef's above. And I found another small buglet too. I hope to post a complete solution later today. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Fri, Jan 11, 2008 at 08:44:28PM +0100, Sam Ravnborg wrote:
> Hi Jan.
>
> On Fri, Jan 11, 2008 at 08:55:29AM +, 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 unconditionally and
> > __cpuinitdata at least in most production kernel configurations also
> > likely evaluates to , 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.
The following patch implment first step in this direction.
It is only an RFC as I have not touched anything else than
64 bit x86 for the arch specific parts.
But it should show what I tried to say above.
On top of x86.git mm-branch.
Sam
diff --git a/arch/x86/kernel/vmlinux_64.lds.S b/arch/x86/kernel/vmlinux_64.lds.S
index ba8ea97..26c1d81 100644
--- a/arch/x86/kernel/vmlinux_64.lds.S
+++ b/arch/x86/kernel/vmlinux_64.lds.S
@@ -155,12 +155,16 @@ SECTIONS
__init_begin = .;
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
+ INIT_TEXT
*(.init.text)
_einittext = .;
}
- __initdata_begin = .;
- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) { *(.init.data) }
- __initdata_end = .;
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
+ __initdata_begin = .;
+ INIT_DATA
+ __initdata_end = .;
+ }
+
. = ALIGN(16);
__setup_start = .;
.init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) { *(.init.setup) }
@@ -187,8 +191,12 @@ SECTIONS
}
/* .exit.text is discard at runtime, not link time, to deal with references
from .altinstructions and .eh_frame */
- .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { *(.exit.text) }
- .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { *(.exit.data) }
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
+ EXIT_TEXT
+ }
+ .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
+ EXIT_DATA
+ }
/* vdso blob that is mapped into user space */
vdso_start = . ;
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 9f584cc..2f359d9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -9,10 +9,48 @@
/* Align . to a 8 byte boundary equals to maximum function alignment. */
#define ALIGN_FUNCTION() . = ALIGN(8)
+#ifdef CONFIG_HOTPLUG
+#define DEV_KEEP(sec)
+#define DEV_DISCARD(sec) *(.dev##sec)
+#else
+#define DEV_KEEP(sec)*(.dev##sec)
+#define DEV_DISCARD(sec)
+#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+#define CPU_KEEP(sec)
+#define CPU_DISCARD(sec) *(.cpu##sec)
+#else
+#define CPU_KEEP(sec)*(.cpu##sec)
+#define CPU_DISCARD(sec)
+#endif
+
+#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \
+|| defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+#define MEM_KEEP(sec)
+#define MEM_DISCARD(sec) *(.mem##sec)
+#else
+#define MEM_KEEP(sec)*(.mem##sec)
+#define MEM_DISCARD(sec)
+#endif
+
+
/* .data section */
#define DATA_DATA \
*(.data)\
*(.data.init.refok) \
+ DEV_KEEP(init.data) \
+ DEV_KEEP(init.data.const) \
+ DEV_KEEP(exit.data) \
+ DEV_KEEP(exit.data.const) \
+ CPU_KEEP(init.data) \
+ CPU_KEEP(init.data.const) \
+ CPU_KEEP(exit.data) \
+ CPU_KEEP(exit.data.const)
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
On Fri, Jan 11, 2008 at 08:44:28PM +0100, Sam Ravnborg wrote:
Hi Jan.
On Fri, Jan 11, 2008 at 08:55:29AM +, 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.
The following patch implment first step in this direction.
It is only an RFC as I have not touched anything else than
64 bit x86 for the arch specific parts.
But it should show what I tried to say above.
On top of x86.git mm-branch.
Sam
diff --git a/arch/x86/kernel/vmlinux_64.lds.S b/arch/x86/kernel/vmlinux_64.lds.S
index ba8ea97..26c1d81 100644
--- a/arch/x86/kernel/vmlinux_64.lds.S
+++ b/arch/x86/kernel/vmlinux_64.lds.S
@@ -155,12 +155,16 @@ SECTIONS
__init_begin = .;
.init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
+ INIT_TEXT
*(.init.text)
_einittext = .;
}
- __initdata_begin = .;
- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) { *(.init.data) }
- __initdata_end = .;
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
+ __initdata_begin = .;
+ INIT_DATA
+ __initdata_end = .;
+ }
+
. = ALIGN(16);
__setup_start = .;
.init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) { *(.init.setup) }
@@ -187,8 +191,12 @@ SECTIONS
}
/* .exit.text is discard at runtime, not link time, to deal with references
from .altinstructions and .eh_frame */
- .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { *(.exit.text) }
- .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { *(.exit.data) }
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
+ EXIT_TEXT
+ }
+ .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
+ EXIT_DATA
+ }
/* vdso blob that is mapped into user space */
vdso_start = . ;
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 9f584cc..2f359d9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -9,10 +9,48 @@
/* Align . to a 8 byte boundary equals to maximum function alignment. */
#define ALIGN_FUNCTION() . = ALIGN(8)
+#ifdef CONFIG_HOTPLUG
+#define DEV_KEEP(sec)
+#define DEV_DISCARD(sec) *(.dev##sec)
+#else
+#define DEV_KEEP(sec)*(.dev##sec)
+#define DEV_DISCARD(sec)
+#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+#define CPU_KEEP(sec)
+#define CPU_DISCARD(sec) *(.cpu##sec)
+#else
+#define CPU_KEEP(sec)*(.cpu##sec)
+#define CPU_DISCARD(sec)
+#endif
+
+#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \
+|| defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE)
+#define MEM_KEEP(sec)
+#define MEM_DISCARD(sec) *(.mem##sec)
+#else
+#define MEM_KEEP(sec)*(.mem##sec)
+#define MEM_DISCARD(sec)
+#endif
+
+
/* .data section */
#define DATA_DATA \
*(.data)\
*(.data.init.refok) \
+ DEV_KEEP(init.data) \
+ DEV_KEEP(init.data.const) \
+ DEV_KEEP(exit.data) \
+ DEV_KEEP(exit.data.const) \
+ CPU_KEEP(init.data) \
+ CPU_KEEP(init.data.const) \
+ CPU_KEEP(exit.data) \
+ CPU_KEEP(exit.data.const) \
+ MEM_KEEP(init.data)
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
+#ifdef CONFIG_HOTPLUG +#define DEV_KEEP(sec) +#define DEV_DISCARD(sec) *(.dev##sec) +#else +#define DEV_KEEP(sec)*(.dev##sec) +#define DEV_DISCARD(sec) +#endif + +#ifdef CONFIG_HOTPLUG_CPU +#define CPU_KEEP(sec) +#define CPU_DISCARD(sec) *(.cpu##sec) +#else +#define CPU_KEEP(sec)*(.cpu##sec) +#define CPU_DISCARD(sec) +#endif + +#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \ +|| defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE) +#define MEM_KEEP(sec) +#define MEM_DISCARD(sec) *(.mem##sec) +#else +#define MEM_KEEP(sec)*(.mem##sec) +#define MEM_DISCARD(sec) +#endif I inversed it in the ifdef's above. And I found another small buglet too. I hope to post a complete solution later today. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
Hi Jan. On Fri, Jan 11, 2008 at 08:55:29AM +, 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 unconditionally and > __cpuinitdata at least in most production kernel configurations also > likely evaluates to , 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] __cpuinitconst and __devinitconst
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 unconditionally and __cpuinitdata at least in most production kernel configurations also likely evaluates to , 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. Patch 1 introduces __cpuinitconst and a single common code consumer. Patch 2 adds a number of x86 consumers of __cpuinitconst. Patch 3 introduces __devinitconst and common code consumers. Patch 4 adds a number of x86 consumers of __devinitconst. Signed-off-by: Jan Beulich <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] __cpuinitconst and __devinitconst
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. Patch 1 introduces __cpuinitconst and a single common code consumer. Patch 2 adds a number of x86 consumers of __cpuinitconst. Patch 3 introduces __devinitconst and common code consumers. Patch 4 adds a number of x86 consumers of __devinitconst. Signed-off-by: Jan Beulich [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] __cpuinitconst and __devinitconst
Hi Jan. On Fri, Jan 11, 2008 at 08:55:29AM +, 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
