Messages in this thread | | | Date | Mon, 20 Jun 2022 14:17:36 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v2] printk: allow direct console printing to be enabled always |
| |
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 }
| |