[U-Boot] [PATCH 2/4] Add ctrlc_ignore environment variable to ignore Ctrl-C

[Simon Glass]

Hi Wolfgang,

On 10 June 2014 01:08, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ2BC0MD6NyoOJRmhYeabm3EYMBs8nQA3hcyD71BB+jqDw at 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