[Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Sergey Senozhatsky]

Hello Steven,

On (07/27/16 22:59), Steven Rostedt wrote:
> > Well, he backed up from that statement later a bit. So when I was
> > discussing this problem with him at last KS he agreed that making printk
> > async is the way to go and he specifically dismissed attempts to print
> > synchronously for a while and fall back to async only later. He just wanted
> > some way to get things to console synchronously once things go bad (oops,
> > panic,...) which is discussed elsewhere in this thread.
> 
> Note, my selftests require synchronous printing, so I hope this feature
> still allows locations to force that without being in oops mode. The
> tracing selftests can cause triple faults, and seeing where it happened
> is a must. I already had issues once when printk changed (temporarily)
> to only dump out lines when a \n was seen. That caused me to think the
> wrong test was rebooting the box.

if you run the tests from user space, then there is a way to change
printk behavior at will. if from kernel, then... there is no really
nice way, as of yet.

you can do something like (ugly)

	console_lock();
	test();
	console_unlock();

or change console_loglevel to CONSOLE_LOGLEVEL_MOTORMOUTH temporarily

	console_verbose();
	test();

or boot with async printk (if needed) then change to sync mode from
user space and then start the test...

by default printk is in sync (old) mode; we don't want to enforce printk
changes on the systems that have never seen any issues with printk. so unless
you pass aync printk boot param or change printk to async from user space,
it must work just as before.

	-ss