如果待处理的字符超过256个，为什么8250 UART驱动程序不唤醒TTY？
这种if条件的动机是什么void serial8250_tx_chars(struct uart_8250_port *up)？ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) uart_write_wakeup(port); 自Linux 1.1.13（1994年5月）以来一直存在，并且在大多数UART驱动程序中都重复使用。 背景：定制的Linux 3.4.91，ARMv7上的嵌入式系统，UART端口0配置为38400波特，I / o使用16字节FIFO。在我们的设置中，所有这些都无法更改。 当的printf-ING 非常沉重经由UART在控制台上，内部的4kB缓冲液（UART_XMIT_SIZE）填满，然后档的用户空间进程直到缓冲器被清空（这需要在38400波特1秒！）。然后，此行为重复。这是因为n_tty_write()当缓冲区已满时，函数将进入睡眠状态，并且由于上述问题而无法长时间唤醒。 如果只删除此检查，我会发现它更自然，更有效。然后，printfs将尽快填充缓冲区，然后以清空缓冲区的速度继续，而不是我观察到的突发处理。 在我的环境中，它可以正常工作，但我肯定会丢失或误解某些东西。当前实施必须有一个理由。如果我消除这种状况，会有副作用吗？ 作为附带的问题：是否有配置选项来调整此行为，例如使printf总是立即返回并在缓冲区已满时丢弃输出？