Dear Simon, In message <CAPnjgZ1HZ5Eh8b15sCgYKrmCqkbT5UBcZWPf6zDvqrebzS2N=a...@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: w...@denx.de "The pathology is to want control, not that you ever get it, because of course you never do." - Gregory Bateson _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
