Hi, On Tue, Oct 8, 2019 at 6:21 AM Daniel Thompson <daniel.thomp...@linaro.org> wrote: > > Currently kdb_read_get_key() contains complex control flow that, on > close inspection, turns out to be unnecessary. In particular: > > 1. It is impossible to enter the branch conditioned on (escape_delay == 1) > except when the loop enters with (escape_delay == 2) allowing us to > combine the branches. > > 2. Most of the code conditioned on (escape_delay == 2) simply modifies > local data and then breaks out of the loop causing the function to > return escape_data[0]. > > 3. Based on #2 there is not actually any need to ever explicitly set > escape_delay to 2 because we it is much simpler to directly return > escape_data[0] instead. > > 4. escape_data[0] is, for all but one exit path, known to be '\e'. > > Simplify the code based on these observations. > > There is a subtle (and harmless) change of behaviour resulting from this > simplification: instead of letting the escape timeout after ~1998 > milliseconds we now timeout after ~2000 milliseconds > > Signed-off-by: Daniel Thompson <daniel.thomp...@linaro.org> > --- > kernel/debug/kdb/kdb_io.c | 38 ++++++++++++++------------------------ > 1 file changed, 14 insertions(+), 24 deletions(-)
Looks great. My only comment is that since this was the 2nd patch in the series I spent a whole bunch of time deducing all these same things when reviewing the first patch. :-P Reviewed-by: Douglas Anderson <diand...@chromium.org> _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
