Messages in this thread | | | Date | Wed, 30 Aug 2017 14:37:34 +0900 | From | Sergey Senozhatsky <> | Subject | Re: printk: what is going on with additional newlines? |
| |
On (08/29/17 19:58), Joe Perches wrote: > > > > > > Why? > > > > > > What's wrong with a simple printk? > > > It'd still do a log_store. > > > > sure, it will. but in separate logbuf entries, and between two > > consequent printk calls on the same CPU a lot of stuff can happen: > > I think you don't quite understand how this would work. > The idea is that the entire concatenated bit would be emitted > in one go.
may be :)
I was thinking about the way to make it work in similar way with printk-safe/printk-nmi. basically seq buffer should hold both continuation and "normal" lines, IMHO. when we emit the buffer we do something like this
/* Print line by line. */ while (c < end) { if (*c == '\n') { printk_safe_flush_line(start, c - start + 1); start = ++c; header = true; continue; }
/* Handle continuous lines or missing new line. */ if ((c + 1 < end) && printk_get_level(c)) { if (header) { c = printk_skip_level(c); continue; }
printk_safe_flush_line(start, c - start); start = c++; header = true; continue; }
header = false; c++; }
except that instead of printk_safe_flush_line() we will call log_store() and the whole loop will be under logbuf_lock.
for that to work, we need API to require header/loglevel etc for every message. so the use case can look like this:
init_printk_buffer(&buf); print_line(&buf, KERN_ERR "Oops....\n");
print_line(&buf, KERN_ERR "continuation line: foo"); print_line(&buf, KERN_CONT "bar"); print_line(&buf, KERN_CONT "baz\n"); ...
print_line(&buf, KERN_ERR "....\n"); ... print_line(&buf, KERN_ERR "--- end of oops ---\n"); emit_printk_buffer(&buf);
so that not only concatenated continuation lines will be handled, but also more complex things. like backtraces or whatever someone might want to handle.
-ss
| |