[Re: [PATCH 2/3] mips:powertv: Make kernel command line size configurable
(resend)] On 08/05/2009 (Fri 09:34) David VomLehn wrote:
> On Fri, May 08, 2009 at 11:25:35AM -0400, Paul Gortmaker wrote:
> > On Mon, May 4, 2009 at 6:57 PM, David VomLehn <dvomlehn@cisco.com> wrote:
> > > Most platforms can get by perfectly well with the default command line
> > > size,
> > > but some platforms need more. This patch allows the command line size to
> > > be configured for those platforms that need it. The default remains 256
> > > characters.
> >
> > The one thing I see when I look at this patch, is that it lands in the
> > arch/mips/Kconfig -- but is there really anything fundamentally
> > architecture specific about the allowed length of the kernel command
> > line?. It probably belongs somewhere alongside the setting for
> > LOG_BUF_LEN or similar (and then add the other respective changes
> > to make all arch actually respect the setting.)
> >
> > Paul.
> >
> > >
> > > Signed-off-by: David VomLehn <dvomlehn@cisco.com>
> > > ---
> > > arch/mips/Kconfig | 7 +++++++
> > > arch/mips/include/asm/setup.h | 2 +-
>
> The reason I put this configuration configuration in the architecture-
> specific Kconfig is because COMMAND_LINE_SIZE is defined in the
> architecture-specific file arch/mips/include/asm/setup.h. I strongly
> agree that this really should not be an architecture-specific definition,
> but it's much more complex to get a patch to change COMMAND_LINE_SIZE
> in every architecture. Fixing in the MIPS tree seems like a good
> start.
It shouldn't be much more complex, at least from a purely technical
point of view (i.e assuming no arch maintainers have a problem with it).
Now, if we tried to get all arch to agree on the same default value,
then I agree that might be more complex/interesting.
All the arch use pretty much the same boilerplate, so something like
this untested patch should work. I thought about hiding it behind
CONFIG_EMBEDDED, but in theory a person could have some big server
blade with a long command line argument too....
Paul.
---------
|