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

[Simon Glass]

Hi Wolfgang,

On Sun, Oct 16, 2011 at 12:52 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ2Qf-Egdp9WCnoWVPJmjic5BPF0Db+z1oD=fdb3aoLNKw at mail.gmail.com> you wrote:
>>
>> > Even worse, if your input contains any commands that prodce output,
>> > mayeb even lots of output (say "md $addr 10000") then even your
>> > increased buffer size is not going to help you.
>>
>> It helps a little - provided there are no more than 250 characters
>> more 'serial input' after the md command, all is well. But I think
>> this example is a little contrived.
>
> 250 characters? That's 4, maybe 5 lines of text.  Not exactly much...

It is 250 characters *behind* the serial input. If the only output on
each line is the U-Boot prompt, then this is perhaps 50 lines of
input, which is plenty for most people.

>
>> I feel this is a painful restriction. I see no indication of this
>> limitation anywhere on the command line, no error or warning, etc. It
>> is common to want to paste in new bootargs, new network parameters,
>> new environment variables. U-Boot has a command line which purports to
>> support this, and with a fairly straightforward patch and in the
>> majority of cases, it can.
>
> Pasting commands is OK for occasional use.  If you use this more
> frequently you're doing something wrong.

I don't understand this comment - it fails every time.

>
>> Yes this is a minor point, but it does bite people, and usability is important.
>
> Agreed.  But consistent behaviour has it's charme as well: it's the
> principle of least surprise (POLS) - see
> http://en.wikipedia.org/wiki/Principle_of_least_surprise

That seems like an argument for this patch. When pasting lines of text
into U-Boot now, the bahaviour is not consistent. Sometimes it drops a
character or two and the system won't boot. Sometimes it fails to
complete and it is clear that something is wrong.

>
> As mentioned before, I'd rather have a clear restriction that is
> consistent on all systems, instead of some "works for me"
> implementation on a few systems that will break under just slightly
> modified usage modes.

Yes, so in summary, we have:

1. The XON/XOFF option, which I will look at. This requires everyone
affected to switch over to XON/XOFF in whatever terminal/ser2net
program they use.

2. Putting a buffer features at the serial port level (one level up
from this patch) to augment the 16-byte FIFO. This would be a pain to
do until someone tidies up serial. We might find a way of emitting a
warning when input overflow occurs. I could look at this but not in
the immediate future. Of course even this option cannot provide
infinite buffer space, that would need to be clearly understood.

3. This patch, which is a point solution for NS16550 only.

It is up to you what you want to select. The patch is up if you want
it, and I should be able to look at XON/XOFF this week.

My preference: option 3 now, option 1 later for those who can use
XON/XOFF, option 2 much much later.

Regards,
Simon

>
> 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
> Uncertain fortune is thoroughly mastered by the equity of the  calcu-
> lation.                                               - Blaise Pascal
>