Hi Wolfgang, On 10 June 2014 01:08, Wolfgang Denk <w...@denx.de> wrote: > Dear Simon, > > In message > <capnjgz2bc0md6nyoojrmhyeabm3eymbs8nqa3hcyd71bb+j...@mail.gmail.com> you > wrote: >> >> > 1) 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. > >> > 2) 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot