Hi Wolfgang,
On 10 June 2014 01:08, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ2BC0MD6NyoOJRmhYeabm3EYMBs8nQA3hcyD71BB+jqDw@mail.gmail.com you wrote:
- 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.
Hm... ignoring it would mean there is no way to interrupt long running commands. I'm not sure if this is actually an improvement. Eventually we should try to define the wanted behaviour first. My initial feelingis that ^C should terminate a running command nd return us to the shell, but not terminate U-Boot. Outside of sandbox, the only regular way to terminate U-Boot is the "reboot" command. Maybe we should do the same in sandbox?
It is very convenient to terminate U-Boot with Ctrl-C - it makes it work like a 'normal' program, and you can still terminate a long-running command - it just quits U-Boot just like any other command-line utility. When quickly running tests it is helpful. Also it is less confusing I think for people who don't know how to exit.
You can use '-t raw' to get the behaviour you want. Is that good enough?
U-Boot sandbox does not yet support 'reboot', but 'reset' does quit U-Boot.
- 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
I'm afraid I don't.
Actually I think I was thinking of Scott Wood's patch:
http://patchwork.ozlabs.org/patch/90066/
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.
The 16550 is on the high end side in terms of capabilities. I don;t thinkwe should "buffer" more than a single character - otherwise it would be just a tiny step to implementing thingslike line disciplines and stuff, and I don;t think we need nor want this.
Yes I wanted to avoid that also. I guess we are left with signal handling as the solution. But for now I might just disable Ctrl-C for sandbox unless the 'raw' terminal is used. That will allow the tests to work correctly at least.
Regards, Simon