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

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ1HZ5Eh8b15sCgYKrmCqkbT5UBcZWPf6zDvqrebzS2N=A at mail.gmail.com> you wrote:
> 
> > 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.

But that's the point: U-Boot with it's CLI is NOT "a 'normal' program".
It's an interactive tool like a shell or an editor.  When you run a
shell (say, bash) as CLI then you also expect that ^C will only
terminate the currently running command, and not exit the shell.

> You can use '-t raw' to get the behaviour you want. Is that good enough?

This should be the default, I think.

> U-Boot sandbox does not yet support 'reboot', but 'reset' does quit U-Boot.

Ah, yes.  Typo.  I meant "reset", of course.

> >> 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/

Ah, this one.  Well, frankly, I don't lioke that for a number of
reasons:

- We have a ton of different UART drivers.Any such implementation
  should be general enough to be usable on more than one type, ideally
  completely hardware independent.
- This buffering of data in this patch is intended to solve a specific
  problem that could be avoided by more clever test scripts.  Instead
  of just dumping an endless stream of characters to the serial
  console independent of what U-Boot is doing, one should always wit
  for the next CLI prompt before sending the next command.  Tools like
  "expect" can do this easily.
- We have to decide what we want.  Either we define the serial input
  system of U-Boot as intentionally simple, allowing it to work with
  minimal resources (like very, very early after reset, long before
  relocation to RAM, i. e. without much space on the stack, without
  writable data segment, without .bss).  Or we want a feature-rich,
  powerful input system with maximum data throuhput, buffering, type
  ahead, line disciplines, etc.  The current implementation is clearly
  following the former design ideas, and I think this is OK so.  The
  second method is indeed more powerful, but quickly caklls for
  additional complexity to implement properly - say, interrupt support
  for the UART drivers, which means we enter a whole new leel of
  complexity.  The current implementation is clearly following the
  former design ideas, and I think this is OK so.  The second method
  is indeed more powerful, but quickly caklls for additional
  complexity to implement properly - say, interrupt support for the
  UART drivers, which means we enter a whole new leel of complexity.

> 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.

As mentioned, I think the default behaviour should be different.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The pathology is to want control, not that you ever get it,  because
of course you never do."                            - Gregory Bateson