printk 在中断处理程序中，真的那么糟糕吗？答案

【问题标题】：printk inside an interrupt handler , is it really that bad?printk 在中断处理程序中，真的那么糟糕吗？
【发布时间】：2012-02-03 01:37:38
【问题描述】：

每个人都知道中断处理程序应该尽可能短。在中断处理程序中添加像printk 这样的函数来调试是不应该做的事情。其实我之前在为我写的一个中断驱动的char设备调试linux内核的时候就试过了，结果破坏了驱动的时序。

我的问题是，为什么会这样？ printk 函数被缓冲！这意味着，据我了解，数据被插入到队列中，并且稍后会处理它，很可能是在中断处理程序完成之后。

那么为什么它不起作用呢？

【问题讨论】：

【解决方案1】：

printk 函数不只是插入队列/缓冲区——假设日志级别足够高，printk 的输出将立即发送到控制台，作为对printk 的调用的一部分.如果控制台位于串行端口上，这会特别慢。但无论如何，printk 确实会引入相当大的开销并且会影响时间。

如果您想要获得一些调试输出的时间关键位置，您可以查看在现代内核中使用trace_printk 函数。这实际上只是将输入放入跟踪环缓冲区，您可以稍后阅读。查看this article了解完整详情。

【讨论】：

【解决方案2】：

是的，这很糟糕，因为printf 很可能是不可重入的。可能发生的情况是主程序调用 printf，在执行 printf 时出现中断，然后 IRQ 处理程序再次调用 printf：可能会发生非常糟糕的事情（例如，死锁、损坏的内部缓冲区等）

【讨论】：

问题是关于printk，而不是printf，它甚至不存在于内核中。而且Linux内核的printk是可重入的，可以从中断上下文等中调用。所以这个答案完全是错误的。
呃，我看错标题了，函数名在他的帖子中有一个古怪的尾随字符：/
说真的，您想在讨论中添加什么？我想知道为什么那个回复没有被标记为否定！