1. Rename saved_command_line into boot_command_line.
2. Set command_line as __initdata.
Signed-off-by: Alon Bar-Lev <[email protected]>
---
arch/arm/kernel/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.20-rc4-mm1/arch/arm/kernel/setup.c
===================================================================
--- linux-2.6.20-rc4-mm1.orig/arch/arm/kernel/setup.c
+++ linux-2.6.20-rc4-mm1/arch/arm/kernel/setup.c
@@ -106,7 +106,7 @@ unsigned long phys_initrd_size __initdat
static struct meminfo meminfo __initdata = { 0, };
static const char *cpu_name;
static const char *machine_name;
-static char command_line[COMMAND_LINE_SIZE];
+static char __initdata command_line[COMMAND_LINE_SIZE];
static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
static union { char c[4]; unsigned long l; } endian_test __initdata = { { 'l', '?', '?', 'b' } };
@@ -803,8 +803,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) &_edata;
init_mm.brk = (unsigned long) &_end;
- memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
- saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
+ memcpy(boot_command_line, from, COMMAND_LINE_SIZE);
+ boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
parse_cmdline(cmdline_p, from);
paging_init(&meminfo, mdesc);
request_standard_resources(&meminfo, mdesc);
--
On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> 2. Set command_line as __initdata.
You can't.
> -static char command_line[COMMAND_LINE_SIZE];
> +static char __initdata command_line[COMMAND_LINE_SIZE];
Uninitialised data is placed in the BSS. Adding __initdata to BSS
data causes grief.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/18/07, Russell King <[email protected]> wrote:
> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > 2. Set command_line as __initdata.
>
> You can't.
>
> > -static char command_line[COMMAND_LINE_SIZE];
> > +static char __initdata command_line[COMMAND_LINE_SIZE];
>
> Uninitialised data is placed in the BSS. Adding __initdata to BSS
> data causes grief.
Thanks for the reply!
There are many places in kernel that uses __initdata for uninitialized
variables.
For example:
./drivers/ide/ide.c:static int __initdata probe_ali14xx;
./drivers/ide/ide.c:static int __initdata probe_umc8672;
./drivers/ide/ide.c:static int __initdata probe_dtc2278;
./drivers/ide/ide.c:static int __initdata probe_ht6560b;
./drivers/ide/ide.c:static int __initdata probe_qd65xx;
static int __initdata is_chipset_set[MAX_HWIFS];
So all these current places are wrong?
If I initialize the data will it be OK.
Best Regards,
Alon Bar-Lev.
Russell King wrote:
> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
>> -static char command_line[COMMAND_LINE_SIZE];
>> +static char __initdata command_line[COMMAND_LINE_SIZE];
>
> Uninitialised data is placed in the BSS. Adding __initdata to BSS
> data causes grief.
>
Static variables are implicitly initialized to zero. Does that also
count as initialization?
tom
On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> Russell King wrote:
> > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> >> -static char command_line[COMMAND_LINE_SIZE];
> >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> >
> > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > data causes grief.
> >
>
> Static variables are implicitly initialized to zero. Does that also
> count as initialization?
No. As I say, they're placed in the BSS. The BSS is zeroed as part of
the C runtime initialisation.
If you want to place a variable in a specific section, it must be
explicitly initialised. Eg,
static char __initdata command_line[COMMAND_LINE_SIZE] = "";
However, there is a bigger question here: that is the tradeoff between
making this variable part of the on-disk kernel image, but throw away
the memory at runtime, or to leave it in the BSS where it will not be
part of the on-disk kernel image, but will not be thrown away at
runtime.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/18/07, Russell King <[email protected]> wrote:
> If you want to place a variable in a specific section, it must be
> explicitly initialised. Eg,
>
> static char __initdata command_line[COMMAND_LINE_SIZE] = "";
>
> However, there is a bigger question here: that is the tradeoff between
> making this variable part of the on-disk kernel image, but throw away
> the memory at runtime, or to leave it in the BSS where it will not be
> part of the on-disk kernel image, but will not be thrown away at
> runtime.
This patch is a result of trying to extend the kernel command-line
size on x86 to more than 256 bytes. People requested to not allocate a
larger buffers for small systems.
I don't know who should decide the tradeoff...
So what you basically say is that many modules need to be fixed...
./arch/avr32/boards/atstk1000/setup.c
./arch/frv/kernel/setup.c
./arch/i386/kernel/acpi/boot.c
./arch/i386/kernel/mpparse.c
./arch/i386/kernel/setup.c
./arch/ia64/kernel/setup.c
<many more>
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev <[email protected]> wrote:
> On 1/18/07, Russell King <[email protected]> wrote:
>> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
>> > 2. Set command_line as __initdata.
>> You can't.
>>
>> > -static char command_line[COMMAND_LINE_SIZE];
>> > +static char __initdata command_line[COMMAND_LINE_SIZE];
>>
>> Uninitialised data is placed in the BSS. Adding __initdata to BSS
>> data causes grief.
> There are many places in kernel that uses __initdata for uninitialized
> variables.
>
> For example:
> static int __initdata is_chipset_set[MAX_HWIFS];
>
> So all these current places are wrong?
> If I initialize the data will it be OK.
objdump -t vmlinux |grep -3 is_chipset_set suggests that it's placed
into .init.data here, not into .bss.
--
Top 100 things you don't want the sysadmin to say:
92. What software license?
Fri?, Spammer: [email protected] [email protected]
* Russell King <[email protected]> [2007-01-18 16:23]:
>
> However, there is a bigger question here: that is the tradeoff between
> making this variable part of the on-disk kernel image, but throw away
> the memory at runtime, or to leave it in the BSS where it will not be
> part of the on-disk kernel image, but will not be thrown away at
> runtime.
Are 1024 bytes of a bigger kernel image really a problem? And even,
normally kernel images are compressed, and compressing 1024 zeros
can be compressed very well.
I think saving memory is more important than saving disk space. I know
that most ARM device use flash disk, but also most ARM devices have
limited RAM.
Regards,
Bernhard
On 1/18/07, Bodo Eggert <[email protected]> wrote:
> Alon Bar-Lev <[email protected]> wrote:
> > On 1/18/07, Russell King <[email protected]> wrote:
> >> On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> >> > 2. Set command_line as __initdata.
>
> >> You can't.
> >>
> >> > -static char command_line[COMMAND_LINE_SIZE];
> >> > +static char __initdata command_line[COMMAND_LINE_SIZE];
> >>
> >> Uninitialised data is placed in the BSS. Adding __initdata to BSS
> >> data causes grief.
>
> > There are many places in kernel that uses __initdata for uninitialized
> > variables.
> >
> > For example:
>
> > static int __initdata is_chipset_set[MAX_HWIFS];
> >
> > So all these current places are wrong?
> > If I initialize the data will it be OK.
>
> objdump -t vmlinux |grep -3 is_chipset_set suggests that it's placed
> into .init.data here, not into .bss.
Russell ?
> On Thu, 18 Jan 2007 15:23:26 +0000 Russell King <[email protected]> wrote:
> On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > Russell King wrote:
> > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > >> -static char command_line[COMMAND_LINE_SIZE];
> > >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> > >
> > > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > > data causes grief.
> > >
> >
> > Static variables are implicitly initialized to zero. Does that also
> > count as initialization?
>
> No. As I say, they're placed in the BSS. The BSS is zeroed as part of
> the C runtime initialisation.
I don't understand the objection. With the above change, command_line[]
will end up consuming COMMAND_LINE_SIZE bytes of .data.init and will be
reliably initialized to all-zeros by the compiler (won't it?)
> If you want to place a variable in a specific section, it must be
> explicitly initialised. Eg,
>
> static char __initdata command_line[COMMAND_LINE_SIZE] = "";
>
> However, there is a bigger question here: that is the tradeoff between
> making this variable part of the on-disk kernel image, but throw away
> the memory at runtime, or to leave it in the BSS where it will not be
> part of the on-disk kernel image, but will not be thrown away at
> runtime.
Yes, it'll take some space in vmlinux. We could perhaps create a new
__initbss to prevent that, I assume.
On Mon, Jan 22, 2007 at 11:56:50AM -0800, Andrew Morton wrote:
> > On Thu, 18 Jan 2007 15:23:26 +0000 Russell King <[email protected]> wrote:
> > On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > > Russell King wrote:
> > > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > > >> -static char command_line[COMMAND_LINE_SIZE];
> > > >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> > > >
> > > > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > > > data causes grief.
> > > >
> > >
> > > Static variables are implicitly initialized to zero. Does that also
> > > count as initialization?
> >
> > No. As I say, they're placed in the BSS. The BSS is zeroed as part of
> > the C runtime initialisation.
>
> I don't understand the objection. With the above change, command_line[]
> will end up consuming COMMAND_LINE_SIZE bytes of .data.init and will be
> reliably initialized to all-zeros by the compiler (won't it?)
You're reading into this something that was never there. The mail you
are replying to is an explanatory one, not an objecting one.
My "objection" (if you want to call it that, it was more an observation)
was that merely adding an __initdata to an uninitialised variable has in
the past caused complaints from compilers about section mismatches and
the like.
Maybe compilers are now smarter though.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hello Andrew,
Can I do anything more in order to be closer to merge?
Some general comments... or should I CC other people etc...
I submitted this several times but got almost no architecture to ACK.
I just don't know how we can progress with this issue... All we wanted
is to break the 256 limit in x86...
Best Regards,
Alon Bar-Lev.
On 1/22/07, Andrew Morton <[email protected]> wrote:
> > On Thu, 18 Jan 2007 15:23:26 +0000 Russell King <[email protected]> wrote:
> > On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > > Russell King wrote:
> > > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > > >> -static char command_line[COMMAND_LINE_SIZE];
> > > >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> > > >
> > > > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > > > data causes grief.
> > > >
> > >
> > > Static variables are implicitly initialized to zero. Does that also
> > > count as initialization?
> >
> > No. As I say, they're placed in the BSS. The BSS is zeroed as part of
> > the C runtime initialisation.
>
> I don't understand the objection. With the above change, command_line[]
> will end up consuming COMMAND_LINE_SIZE bytes of .data.init and will be
> reliably initialized to all-zeros by the compiler (won't it?)
>
> > If you want to place a variable in a specific section, it must be
> > explicitly initialised. Eg,
> >
> > static char __initdata command_line[COMMAND_LINE_SIZE] = "";
> >
> > However, there is a bigger question here: that is the tradeoff between
> > making this variable part of the on-disk kernel image, but throw away
> > the memory at runtime, or to leave it in the BSS where it will not be
> > part of the on-disk kernel image, but will not be thrown away at
> > runtime.
>
> Yes, it'll take some space in vmlinux. We could perhaps create a new
> __initbss to prevent that, I assume.
>
>
On Mon, 22 Jan 2007 22:31:48 +0200
"Alon Bar-Lev" <[email protected]> wrote:
> Hello Andrew,
>
> Can I do anything more in order to be closer to merge?
Avoid top-posting? ;)
> Some general comments... or should I CC other people etc...
> I submitted this several times but got almost no architecture to ACK.
>
> I just don't know how we can progress with this issue... All we wanted
> is to break the 256 limit in x86...
yes, the patches looked reasonable-looking. But iirc they were against
2.6.19 which is prehistoric. Please redo and resend against a development
kernel.
* Andrew Morton <[email protected]> [2007-01-22 21:44]:
>
> > Some general comments... or should I CC other people etc...
> > I submitted this several times but got almost no architecture to ACK.
> >
> > I just don't know how we can progress with this issue... All we wanted
> > is to break the 256 limit in x86...
>
> yes, the patches looked reasonable-looking. But iirc they were against
> 2.6.19 which is prehistoric. Please redo and resend against a development
> kernel.
I refreshed the patches from Alon against 2.6.20-rc4-mm1. Or was I
totally wrong?
Regards,
Bernhard
--
SUSE LINUX Products GmbH E-Mail: [email protected]
Maxfeldstr. 5 Phone: +49 (911) 74053-0
90409 N?rnberg, Germany
OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6 BA4B 8865 3696 DDAF 6454
On 1/22/07, Bernhard Walle <[email protected]> wrote:
> I refreshed the patches from Alon against 2.6.20-rc4-mm1. Or was I
> totally wrong?
I don't know what is "Avoid top-posting? ;)" I hope it is a good thing... :)
I will look at it again and submit it as requested.
Thank you,
Alon Bar-Lev.
* Russell King <[email protected]> [2007-01-18 16:23]:
> On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > Russell King wrote:
> > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > >> -static char command_line[COMMAND_LINE_SIZE];
> > >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> > >
> > > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > > data causes grief.
> > >
> >
> > Static variables are implicitly initialized to zero. Does that also
> > count as initialization?
>
> No. As I say, they're placed in the BSS. The BSS is zeroed as part of
> the C runtime initialisation.
>
> If you want to place a variable in a specific section, it must be
> explicitly initialised. Eg,
>
> static char __initdata command_line[COMMAND_LINE_SIZE] = "";
Why? It must be initialised if you rely on a initialised value in the
code. But I don't think that this in in case here. Can you tell me the
code where you read from command_line before writing to it?
Thanks.
Regards,
Bernhard
On Mon, Jan 22, 2007 at 11:14:00PM +0100, Bernhard Walle wrote:
> * Russell King <[email protected]> [2007-01-18 16:23]:
> > On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > > Russell King wrote:
> > > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > > >> -static char command_line[COMMAND_LINE_SIZE];
> > > >> +static char __initdata command_line[COMMAND_LINE_SIZE];
> > > >
> > > > Uninitialised data is placed in the BSS. Adding __initdata to BSS
> > > > data causes grief.
> > > >
> > >
> > > Static variables are implicitly initialized to zero. Does that also
> > > count as initialization?
> >
> > No. As I say, they're placed in the BSS. The BSS is zeroed as part of
> > the C runtime initialisation.
> >
> > If you want to place a variable in a specific section, it must be
> > explicitly initialised. Eg,
> >
> > static char __initdata command_line[COMMAND_LINE_SIZE] = "";
>
> Why? It must be initialised if you rely on a initialised value in the
> code.
That comment most certainly is 100% incorrect. The following:
static char foo[16];
has a well defined value when you read from it before writing to it.
If you think otherwise, suggest you read any specification of the C
language.
> But I don't think that this in in case here. Can you tell me the
> code where you read from command_line before writing to it?
That wasn't my point.
Anyway, here's what the GCC manual has to say about use of
__attribute__((section)) on variables:
`section ("SECTION-NAME")'
Use the `section' attribute with an _initialized_ definition of a
_global_ variable, as shown in the example. GCC issues a warning
and otherwise ignores the `section' attribute in uninitialized
variable declarations.
You may only use the `section' attribute with a fully initialized
global definition because of the way linkers work. The linker
requires each object be defined once, with the exception that
uninitialized variables tentatively go in the `common' (or `bss')
section and can be multiply "defined". You can force a variable
to be initialized with the `-fno-common' flag or the `nocommon'
attribute.
which reflects precisely what I've been saying concerning the addition
of __initdata.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
* Russell King <[email protected]> [2007-01-22 23:27]:
>
> which reflects precisely what I've been saying concerning the addition
> of __initdata.
100 % correct, thanks.
Regards,
Bernhard
On 1/23/07, Russell King <[email protected]> wrote:
> which reflects precisely what I've been saying concerning the addition
> of __initdata.
Great!
So what do you thing we should do?
Modify this:
char __initdata boot_command_line[COMMAND_LINE_SIZE];
Into:
char __initdata boot_command_line[COMMAND_LINE_SIZE] = {0};
Or:
static char __initdata _boot_command_line[COMMAND_LINE_SIZE];
char __initdata *boot_command_line = _boot_command_line;
Or any other option... I will glad to receive any convention you see right.
Best Regards,
Alon Bar-Lev.
On Tue, Jan 23, 2007 at 12:37:06PM +0200, Alon Bar-Lev wrote:
> On 1/23/07, Russell King <[email protected]> wrote:
> >which reflects precisely what I've been saying concerning the addition
> >of __initdata.
>
> Great!
> So what do you thing we should do?
>
> Modify this:
> char __initdata boot_command_line[COMMAND_LINE_SIZE];
>
> Into:
> char __initdata boot_command_line[COMMAND_LINE_SIZE] = {0};
>
> Or:
> static char __initdata _boot_command_line[COMMAND_LINE_SIZE];
> char __initdata *boot_command_line = _boot_command_line;
>
> Or any other option... I will glad to receive any convention you see right.
See Message-ID: <[email protected]> sent on
18 January in this thread. Such strings might as well be initialised to
an empty string.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/23/07, Russell King <[email protected]> wrote:
> See Message-ID: <[email protected]> sent on
> 18 January in this thread. Such strings might as well be initialised to
> an empty string.
So it will be fine if I initialize it to "" and remove the static from
the your example?
BTW: Is there a difference between "" and initialize it to {0}?
Thanks for you help!
Alon Bar-Lev.
On Tue, Jan 23, 2007 at 12:50:15PM +0200, Alon Bar-Lev wrote:
> On 1/23/07, Russell King <[email protected]> wrote:
> >See Message-ID: <[email protected]> sent on
> >18 January in this thread. Such strings might as well be initialised to
> >an empty string.
>
> So it will be fine if I initialize it to "" and remove the static from
> the your example?
Why do you want to remove the static?
> BTW: Is there a difference between "" and initialize it to {0}?
Not in the end result. However, "" is a string but {0} is an array.
So, "" helps to say to the reader "we're treating this as a string".
Also, "" is quicker to type than {0}.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/23/07, Russell King <[email protected]> wrote:
> Why do you want to remove the static?
Since current design declare a buffer in main.c which is used by arch
specific startup code, mainly setup.c.
Regards,
Alon Bar-Lev.
On 1/23/07, Russell King <[email protected]> wrote:
> > So it will be fine if I initialize it to "" and remove the static from
> > the your example?
>
> Why do you want to remove the static?
Rossell, I am confused.
There are many places in kernel where there is static __initdata
without initialization. Should all these be corrected too? Or your
comment applies only to none static global data?
Best Regards,
Alon Bar-Lev.
On Tue, Jan 23, 2007 at 01:31:25PM +0200, Alon Bar-Lev wrote:
> On 1/23/07, Russell King <[email protected]> wrote:
> >> So it will be fine if I initialize it to "" and remove the static from
> >> the your example?
> >
> >Why do you want to remove the static?
>
> Rossell, I am confused.
> There are many places in kernel where there is static __initdata
> without initialization. Should all these be corrected too? Or your
> comment applies only to none static global data?
>From what I remembered from previous mails on this list (which is what
caused me to pick up on this), and what I later quoted from the gcc
manual, all those places (where something is marked __initdata but is
not explicitly initialised) would appear to be incorrect.
So they should probably be fixed up.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 1/23/07, Russell King <[email protected]> wrote:
> > Rossell, I am confused.
> > There are many places in kernel where there is static __initdata
> > without initialization. Should all these be corrected too? Or your
> > comment applies only to none static global data?
>
> From what I remembered from previous mails on this list (which is what
> caused me to pick up on this), and what I later quoted from the gcc
> manual, all those places (where something is marked __initdata but is
> not explicitly initialised) would appear to be incorrect.
>
> So they should probably be fixed up.
Well... A lot of places in the kernel needs to be fixed, regardless
this patch... I can probably creat a patch for this as well... But
since I don't an expert in this one... We need to be sure this should
be fixed.
Best Regards,
Alon Bar-Lev.
On Tue, Jan 23, 2007 at 01:59:14PM +0200, Alon Bar-Lev wrote:
> On 1/23/07, Russell King <[email protected]> wrote:
> >> Rossell, I am confused.
> >> There are many places in kernel where there is static __initdata
> >> without initialization. Should all these be corrected too? Or your
> >> comment applies only to none static global data?
> >
> >From what I remembered from previous mails on this list (which is what
> >caused me to pick up on this), and what I later quoted from the gcc
> >manual, all those places (where something is marked __initdata but is
> >not explicitly initialised) would appear to be incorrect.
> >
> >So they should probably be fixed up.
>
> Well... A lot of places in the kernel needs to be fixed, regardless
> this patch... I can probably creat a patch for this as well... But
> since I don't an expert in this one... We need to be sure this should
> be fixed.
Don't particularly care; the amount of time spent discussing this issue
is becoming rather rediculous, so I'd rather we reached some conclusion
very soon; to this end this is going to be my last response on this
subject.
I suggest that we leave what's already there, but any new instances we
create are correct to the gcc manual.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: