Hi Joe,
On 9 July 2018 at 13:26, Joe Hershberger joe.hershberger@ni.com wrote:
On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 2 July 2018 at 18:06, Joe Hershberger joe.hershberger@ni.com wrote:
In raw mode, handle ctrl-c as normal. This allows normal ctrl-c behavior such as aborting a command that is timing out without completely terminating the sandbox executable.
In [1], Simon disabled this. His reason for it was that it interferes with piping test scripts. Piping should be done in cooked mode, so this change should still not interfere.
[1] commit 8969ea3e9f2db04a6b3675 ("sandbox: Disable Ctrl-C")
Signed-off-by: Joe Hershberger joe.hershberger@ni.com
common/console.c | 2 -- drivers/serial/sandbox.c | 3 +++ 2 files changed, 3 insertions(+), 2 deletions(-)
It is designed so that ctrl-C exits in raw mode. That is the normal behaviour for an application and I don't think sandbox should be any different.
How about using cooked mode instead?
That seems backward. Only in raw mode (STATE_TERM_RAW) is the console not interfering with keyboard inputs and changing behaviors based on interpreting control codes. In raw mode, U-Boot sandbox can handle things the way it does in real hardware.
To be clear, this is not the default case (STATE_TERM_RAW_WITH_SIGS) where ctrl-C exits. In fully raw mode (STATE_TERM_RAW), ctrl-C does absolutely nothing without this patch.
Also, if cooked mode were used, it would once again break the test script piping that your previous commit talked about. I'm not sure exactly what that applies to (would it affect Travis such that I can validate interference?) so I'm not sure I've tested that use-case effectively.
Er yes, sorry, I mean raw mode. I misunderstood your commit message I think.
Reviewed-by: Simon Glass sjg@chromium.org
Regards, Simon