Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

Hello,

On (06/19/17 17:54), Hannes Reinecke wrote:
[..]
> > Developers machine probably have different requirements to production
> > machines. When debugging during code development, i want the debug
> > output to be in the correct order, independent of the level. If you
> > are going to cause reordering, you might want to add a sequence number
> > to each output, so it is possible to put it back into the correct
> > order. And it needs to be clear when output is out of order.
> > 
> I was under the impression that we do this anyway; even ATM every line
> in the printk buffer is prefixed with a timestamp.
> And we should continue with that.
> 
> Obviously, this requires that any printk buffer entry which is _not_
> time-critical (ie everything not in 1) or 2) _cannot_ be broken up, but
> will always end up as one record in the printk buffer.
> If we could achieve that all the logging infrastructure in scsi could go
> away and I could use 'normal' printk.
> Now _that_ would be really cool.

are we talking about dev_printk() and friends here? if so, then yes - would
be lovely to remove those.

there is some demand for a 'buffered printk' - multiple lines that would
appear in logbuf in sequential records. people (Tetsuo) want OOM backtraces
from different CPUs to be less broken up, etc.

we already have per-CPU buffers for printk_safe and we can reuse them.
there are some limitations, tho. if "buffered printk must be done with
local IRQs disabled" trade-off is acceptable (and I kinda think it is,
buffered printk from a scheduleable context is somewhat strange), then
we can add it _more or less_ easily.

very schematically

	buffered_printk_begin();  //local IRQ disable
		printk();
		printk();
		...
		printk();

	buffered_printk_end()   // local IRQ enable
		{
			spin_lock_irqsave(logbuf_lock)

				copy messages from this-CPU buffer to logbuf

			spin_unlock_irqrestore(logbuf_lock)
		}

	-ss