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

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

Hello,

On (07/20/16 15:54), Josh Triplett wrote:
[..]
> > That's what I've tried to infer by the above statement; KERN_EMERG could
> > easily used for that sort of thing.
> 
> I don't mean using just the priority level of the printk call.  I mean
> using the current kernel loglevel, as in what level it displays to the
> console, as set on the kernel command line with the loglevel= parameter.
> printk could quickly check the priority level of the call versus the
> current kernel loglevel to determine if the message would go to the
> console or not, and use that to decide whether to handle it
> synchronously or asynchronously.

between loglevel check in printk() and actual printing console loglevel
may change. thus printk() does not make this (severity level filtering)
decision. console_unlock() does, on per-log record basis:

console_unlock()
{
	for (;;) {
		spin_lock(logbuf_lock)

skip:
		msg = log_from_idx(console_idx);
		if (msg->level >= console_loglevel)
			goto skip;

		spin_unlock(logbuf_lock)

		call_console_drivers(text)
	}
}

and by the time we call console_unlock() we better already be
either in async mode, or sync mode. unless we want to rewrite
console_unlock().

	-ss