Messages in this thread | ![/](/images/icornerl.gif) | | From | Doug Anderson <> | Date | Wed, 9 Oct 2019 10:28:36 -0700 | Subject | Re: [PATCH v2 3/5] kdb: Remove special case logic from kdb_read() |
| |
Hi,
On Wed, Oct 9, 2019 at 2:30 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > > > @@ -183,17 +186,7 @@ static int kdb_read_get_key(char *buffer, size_t bufsize) > > > * function. It is not reentrant - it relies on the fact > > > * that while kdb is running on only one "master debug" cpu. > > > * Remarks: > > > - * > > > - * The buffer size must be >= 2. A buffer size of 2 means that the caller only > > > - * wants a single key. > > > > By removing this you broke "BTAPROMPT". So doing: > > > > set BTAPROMPT=1 > > bta > > > > It's now impossible to quit out. Not that I've ever used BTAPROMPT, > > but seems like we should either get rid of it or keep it working. > > Thanks. Just to check I got exactly what you meant I assume this could > also have been phrased as "it looks like you forgot to convert the > kdb_getstr() in kdb_bt1() over to use the new kdb_getchar() function"?
Right. Sorry for wording it in a confusing way. ;-)
> > > @@ -741,7 +732,7 @@ int vkdb_printf(enum kdb_msgsrc src, const char *fmt, va_list ap) > > > > > > /* check for having reached the LINES number of printed lines */ > > > if (kdb_nextline >= linecount) { > > > - char buf1[16] = ""; > > > + char ch; > > > > The type of "ch" should be the same as returned by kdb_getchar()? > > Either "int" if you're keeping it "int" or "unsigned char"? > > Probably... although the assumption that kdb strings are char * is burnt > in a lot of places so there will still be further tidy up needed.
True. It doesn't matter a whole lot so if you think it's easier to keep it as char that's OK too.
-Doug
| ![\](/images/icornerr.gif) |