[U-Boot] [PATCH v3 3/3] config: Remove Blackfin CONFIG_DEPRECATED_SILENT_LINUX_CONSOLE

[Wolfgang Denk]

Dear Doug,

In message <CAD=FV=Ui2Zww2bGT+QSjTg=K0v9BGGSAxShrTsXOQyPbA9XRSg at mail.gmail.com> you wrote:
> 
> ...I'm still awaiting Wolfgang's suggestion for which of the following
> he'd like me to submit instead of this series:
> 
> 1. A stripped down version of the change to use malloc with the caveat
> that it's up to the user not to overrun any hardcoded limits in the
> kernel (I'm pretty sure that the kernel already has code to
> truncate--at least on most platforms).
> 
> 2. A version of the change to add a platform-specific
> COMMAND_LINE_SIZE to u-boot (keeping in sync with the kernel) with a
> fix in u-boot to never buffer overrun (changing behavior to truncate).

I have to admit that I have no clear opinion here yet.

The existing code is from a time when all architectures had a pretty
low limit on the command line size - IIRC even PPC had only 256 bytes
by then, hard coded.

I think we have two options:

1) Try not to exceed any limits imposed by the Linux kernel.
   Advantage: we can catch situations where the user overflows the
           limits and print an error message (IIRC this needs to be
           added), so the user gets aware of the pronlem.
   Disadvantage: we need to add architecture specific definitions for
           the command line size, and keep these in sync with any
	   related changes to the Linux kernel.  We know in advance
	   that this will not work really well.

2) We just make sure not to overwrite array bounds in U-Boot, and
   allow passing arbitrary sized buffers to the Linux kernel.
   Advantage: the code in U-Boot can be simple and clean
   Disadvantage: the resulting behaviour is not exactly user-friendly,
           as a silent truncation in the Linux kernel is probably hard
	   to spot.

Hm...

I agree that the old code needs fixing.  I think it would be nice if
we could adapt U-Boot behaviour, but I fear that actually it cannot
work at all, as we don't know which Linux kernel version the user will
use, and what their limits might be.

So in the end 2) is probably the most sensible approach here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
THIS IS A 100% MATTER  PRODUCT:  In  the  Unlikely  Event  That  This
Merchandise  Should  Contact  Antimatter  in Any Form, a Catastrophic
Explosion Will Result.