Hi Wolfgang,
On 6 June 2014 16:10, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ15jrh=-tEj-0tFjwBSZyq+0BihKJLEjG3d43wQOowMFg@mail.gmail.com you wrote:
If this happens, I consider it a bug that should be fixed, and not papered over.
If you look at the code for the 'md' command it calls ctrlc() every now and then. Each call results in a getc() which reads a character from the console. So we lose characters.
Well, as I mentioned: it looks like a bug that needs fixing.
I dislike this idea. It looks wrong to me. Can we not fix the problem at the root cause?
I certainly thought about this. I even though maybe we might change the serial module to scan ahead and buffer characters, in case there is a Ctrl-C in the future. But that itself seems like something for the future.
well, I see two sides of this:
- Looking at sandbox only, we should provide an implementation of ctrlc() that does not consume characters from stdin - I thinkwe should rather be able to react on signals?
Currently there is no signal handling, but we set up the terminal so that Cltr-C terminates U-Boot (default) or does not (and it appears as a character in the input). It's probably a bit more complicated but it should be doable. We can probably just ignore Cltl-C on sandbox for now.
- With a general point of view, consuming characters for no good is always wrong and needs to be fixed.
I'm not sure if you recall the serial driver buffer patch I sent for ns16550 which corrected this problem and also dealt with serial input overflow while outputting to the LCD. We might consider resurrecting this and doing it at a higher level. Without buffering I don't see any way to fix this.
Regards, Simon