linux-mips
[Top] [All Lists]

Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN

To: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Subject: Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN
From: David Daney <ddaney@caviumnetworks.com>
Date: Fri, 06 Nov 2009 08:44:27 -0800
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
In-reply-to: <90edad820911060834t5c14aa30t847c3b75bf7e36e@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20091107.010839.246840249.anemo@mba.ocn.ne.jp> <90edad820911060822g40233a8ft28001d68186b989e@mail.gmail.com> <90edad820911060834t5c14aa30t847c3b75bf7e36e@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Dmitri Vorobiev wrote:
On Fri, Nov 6, 2009 at 6:22 PM, Dmitri Vorobiev
<dmitri.vorobiev@gmail.com> wrote:
On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512.
(commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE")

This cause warning if something like buf[CL_SIZE] was declared as a
local variable, for example in prom_init_cmdline() on some platforms.

And since many Makefiles in arch/mips enables -Werror, this cause
build failure.

How can we avoid this error?

- do not use local array? (but dynamic allocation cannot be used in
 such an early stage.  static array?)
Maybe a static array marked with __initdata?

Also, I just thought that maybe it's possible to use a c99
variable-length array here? Like this:

int n = COMMAND_LINE_SIZE;
char buf[n];

This way, we don't put yet another variable in the .init.data section,
unlike with the static array solution.

However, this is totally untested, just a thought...


It depends on your concerns. You are still using 4096 bytes of stack, but you are trying to trick the compiler into not warning.

If you think the warning is bogus, you should remove it for all code, not just this file. If you think the warning is valid, then you should fix the code so that it doesn't use as much stack space.

David Daney

<Prev in Thread] Current Thread [Next in Thread>