> So is trying to printk() a 1Kb log line over 9600 baud. That's nearly > a second with interrupts off; good luck with that. > > While on one hand, this seems like a flaw that we should be fixing, > on the the other hand, it is self-evident that serial console is > not the solution to every problem. > > I'm sure most kernel developers have experienced losing control of the > machine from console spew that never ends; which is why ftrace can be > so useful. I agree that it's impossible to fix 100%. Because console printk can happen from anywhere (specifically including a kmalloc(GFP_ATOMIC)), the input side must not take *any* locks, meaning it must not to *any* allocations; all memory it uses must be preallocated. And to guarantee no drops, you'd need enough space to accommodate the longest possible printk spew. Which, as you note, is not actually bounded. So preallocating enough space is impossible. (As we agreed last time, the baud rate is actually irrelevant; it's just the number of characters.) But it *is* possible to greatly ameliorate the situation. If the machine s *not* saturating the serial console, the few hundred bytes of buffers the serial port normally keeps around would handle a lot of debug messages. And the tty_buffers are already lockless. Doing this is extremely possible. It's making the code clean enough that's the PITA that resulted in it getting pushed down my stack. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
