Hi Wolfgang, On 6 June 2014 16:10, Wolfgang Denk <w...@denx.de> wrote: > Dear Simon, > > In message > <CAPnjgZ15jrh=-tej-0tfjwbszyq+0bihkjlejg3d43wqoow...@mail.gmail.com> you > wrote: >> >> > If this happens, I consider it a bug that should be fixed, and not >> > papered over. >> >> If you look at the code for the 'md' command it calls ctrlc() every >> now and then. Each call results in a getc() which reads a character >> from the console. So we lose characters. > > Well, as I mentioned: it looks like a bug that needs fixing. > >> > I dislike this idea. It looks wrong to me. Can we not fix the problem >> > at the root cause? >> >> I certainly thought about this. I even though maybe we might change >> the serial module to scan ahead and buffer characters, in case there >> is a Ctrl-C in the future. But that itself seems like something for >> the future. > > well, I see two sides of this: > > 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. > > 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 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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
