On Tue, Jul 10, 2018 at 3:49 PM, Simon Glass <s...@chromium.org> wrote:
> Hi Joe,
> On 9 July 2018 at 13:26, Joe Hershberger <joe.hershber...@ni.com> wrote:
>> On Sun, Jul 8, 2018 at 9:39 PM, Simon Glass <s...@chromium.org> wrote:
>>> Hi Joe,
>>> On 2 July 2018 at 18:06, Joe Hershberger <joe.hershber...@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 , 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.
>>>>  commit 8969ea3e9f2db04a6b3675 ("sandbox: Disable Ctrl-C")
>>>> Signed-off-by: Joe Hershberger <joe.hershber...@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
>>> 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
> Er yes, sorry, I mean raw mode. I misunderstood your commit message I think.
> Reviewed-by: Simon Glass <s...@chromium.org>
You want to take this series in or should I?
U-Boot mailing list