[U-Boot] [PATCH 2/2] sandbox: Don't disable ctrlc() on sandbox if in raw mode

Joe Hershberger joe.hershberger at ni.com
Mon Jul 9 19:26:21 UTC 2018


On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Joe,
>
> On 2 July 2018 at 18:06, Joe Hershberger <joe.hershberger at 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 at 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.

Thanks,
-Joe


More information about the U-Boot mailing list