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

Wolfgang Denk
2012-01-11T08:11:01Z

Dear Doug,

In message <CAD=FV=Ui2Zww2bGT+QSjTg=K0v9BGGSAxShrTsXOQyPbA9XRSg@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.