On Thu 2018-11-08 21:30:49, Sergey Senozhatsky wrote:
> On (11/08/18 12:24), Petr Mladek wrote:
> > > - It seems that buffered printk attempts to solve too many problems.
> > > I'd prefer it to address just one.
> >
> > This API tries to handle continuous lines more reliably.
> > Do I miss anything, please?
>
> This part:
>
> + /* Flush already completed lines if any. */
> + for (pos = ptr->len - 1; pos >= 0; pos--) {
> + if (ptr->buf[pos] != '\n')
> + continue;
> + ptr->buf[pos++] = '\0';
> + printk("%s\n", ptr->buf);
> + ptr->len -= pos;
> + memmove(ptr->buf, ptr->buf + pos, ptr->len);
> + /* This '\0' will be overwritten by next vsnprintf() above. */
> + ptr->buf[ptr->len] = '\0';
> + break;
> + }
> + return r;
>
> If I'm not mistaken, this is for the futute "printk injection" work.
No, it does not make sense to distinguish the context at this level.
The buffer is passed as an argument. It should not get passed to another
task or context.
The above code only tries to push complete lines to the main log buffer
and consoles ASAP. It sounds like a Good Idea(tm).
> Right now printk("foo\nbar\n") will end up to be a single logbuf
> entry, with \n in the middle and at the end. So it will look like
> two lines on the serial console:
>
> [123.123] foo
> bar
>
> Tetsuo does this \n lookup (on every vprintk_buffered) and split lines
> (via memove) for "printk injection", so the output will be
>
> [123.123] foo
> [123.124] bar
No, please note that the for cycle searches for '\n' from the end
of the string.
> Which makes it simpler to "inject" printk origin into every printed
> line.
>
> Without it we can just do
>
> len = vsprintf();
> if (len && text[len - 1] == '\n' || overflow)
> flush();
I had the same idea. Tetsuo ignored it. I looked for more arguments
and found that '\n' is used in the middle of several pr_cont()
calls, see
git grep 'pr_cont.*\\n.*[^\\n]"'
Best Regards,
Petr
