Messages in this thread | | | Date | Wed, 30 Aug 2017 11:47:03 +0900 | From | Sergey Senozhatsky <> | Subject | Re: printk: what is going on with additional newlines? |
| |
On (08/29/17 19:31), Joe Perches wrote: [..] > > the idea is not to do printk() on that seq buffer at all, but to > > log_store(), atomically, seq buffer messages > > > > spin_lock(&logbuf_lock) > > while (offset < seq_buffer->len) { > > ... > > log_store(seq->buffer + offset); > > ... > > } > > spin_unlock(&logbuf_unlock) > > 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: IRQs->printks, rescheduling->printks, etc. etc. (not to mention concurrent printks from other CPUs) so what people want to have is to have a way to make several printks appear next to each other in the logs (dmesg or serial log). Tetsuo wants this, for instance, for OOM reports and backtraces. SCIS/ATA people want it as well.
-ss
| |