Re: [PATCH v2] printk: allow direct console printing to be enabled always

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (22/06/20 01:23), John Ogness wrote:
> I'm wondering if we should output a message here. My suggestion is:
> 
> pr_info("printing threads disabled, using direct printing\n");
> 
> > +		return 0;
> > +
> >  	console_lock();
> >  	printk_kthreads_available = true;
> >  	for_each_console(con)
> 
> Otherwise it looks OK to me. But you may want to wait on a response from
> Petr, Sergey, or Steven before sending a v3. You are adding a kernel
> config and a boot argument. Both of these are sensitive topics that
> require more feedback from others.

A tricky situation. I think John already mentioned in another thread
that any such config/boot param potentially can become a default value
for some setups; at the same time, well, yeah, I see what commit message
talks about.

May I just dump some thoughts?

I guess user-space "[+] some userspace command" are write()-s to /dev/ttyX
which end up in uart circular buffer and which are printed from console
IRQ handler (where it handles both TX and RX)

	console_irq()
	{
		int count = XXX;

		spin lock irqsafe port->lock

		RX

		do {
			TX char from xmit->buf
		} while (--count);

		spin unlock irqrestore port->lock
	}

The "[    1.2345 ] some kernel log output" (which I assume are printed
by user-space from some syscall?) now take a much more lengthy path to
console and are always async/deferred.

I know that John and Petr (rightfully so) will hate what I'm about to
say, but would it make sense/be possible/etc. to look into possibility
to address that "deferred kthread vs IRQ" race by moving prb entries
emit to the same IRQ handler that emits chars from uart xmit buffer?
In other words:

	console_irq()
	{
		int count = XXX;

		spin lock irqsafe port->lock

		RX

		do {
			TX char from xmit->buf
		} while (--count);

+		count = XXX;
+		do {
+			console_emit_next_record();
+		} while (--count);

		spin unlock irqrestore port->lock
	}