[U-Boot] [PATCH v2] NS16550: buffer reads

[Wolfgang Denk]

Dear Scott Wood,

In message <4EA83B88.8040109 at freescale.com> you wrote:
>
> The point here is to make an incremental improvement that solves a
> problem for some people (even if not "solving" the general problem),

Sorry, but this is not an improment in any way, even if it looks so at
first glance.  Actually it's papering over the bugs that result from
mis-use of the given user interface, without actually providing a fix.

Instead of making the users aware of correct use, and providing help
to do so, this makes people believe that serial input was a reliable
transfer medium and will accept any amount of data dumped to it.

I can only repeat (and I think I'll do this for the last time in this
thread):

- Patches are welcome that allow to overcome this existing limitation
  are welcome - butt hese must provide a reliablke solution that works
  in (at least nearly) all test cases.

- Failure to process multi-line input is a restriction, and if you
  like you may even consider it a bug.  But papering over that bug and
  suggesting to the end users that they are allowed to use multi-line
  input while we all know very well that it actually works only under
  certain (somewhar fragile) assumptions is a fraudulent misrepresen-
  tation.

The approaches discussed so far all have issues. So far I don't see
an approach that appears to be generally usable, clean in design and
reliable in operation.


Regarding this specific patch you submitted: I made my mind up, and I
reject it for the resons given above and in previous messages.

Regarding approaches to lift this restriction: I insist on a clean
design.  It would be helpful if we could base this on a clean driver
model, but we are not there yet - nevertheless, we should keep that in
mind.  Iam also pretty much convinced that the implementation must be
contained within the serial input driver layer, without need to change
"application" code or to put restrictions on the behaviour of any code
that reads or writes from resp. to the console in genral, and the
serial port in particular.

Any code to test one approach or another is welcome, even if it's
half-baked.  But I will not accept such prelimiary code for mainline
that "solves a problem for some people" without actually fixing it.

Thanks.

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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.