问题描述
每个人都知道中断处理程序应该尽可能短.并且添加诸如 printk 之类的函数用于在中断处理程序中进行调试是不应该做的.其实我之前在调试linux内核的时候，我写的一个中断驱动的char设备的时候试过，它破坏了驱动程序的时序.
everybody knows that interrupt handler should be short as possible. and adding functions like printk for debugging inside an interrupt handler is something that shouldn't be done.Actually, I tried it before when I was debugging the linux kernel for an interrupt driven char device I written, and it wrecked the timing of the driver.
我的问题是，为什么会发生这种情况?printk 函数被缓冲了！这意味着，据我所知，数据被插入到队列中，并且稍后被处理，很可能是在中断处理程序完成之后.
The question I have, is why this is happening ?printk function is buffered ! it means, as far as I understand that the data is inserted in to a queue, and it's being handled later, most probably after the interrupt handler is finished.
那为什么不起作用?
推荐答案
printk 函数不仅仅是插入到队列/缓冲区中——假设日志级别足够高，printk 的输出code>printk 将立即发送到控制台，作为对 printk 调用的一部分.如果控制台位于串行端口上，则这尤其慢.但无论如何，printk 确实引入了相当大的开销并且会影响时间.
The printk function is not just inserting into a queue/buffer -- assuming the log level is high enough, the output from printk will be emitted to the console immediately, as part of the call to printk. This is especially slow if the console is, say, on a serial port. But in any case, printk does introduce pretty substantial overhead and can affect timing.
如果您想获得一些调试输出的时间关键位置，您可以查看在现代内核中使用 trace_printk 函数.这实际上只是将输入放入跟踪环缓冲区，您可以稍后读取它.查看这篇文章了解完整详情.
If you have a timing critical place where you want to get some debug output, you can look at using the trace_printk function in modern kernels. This actually does just put input into the trace ringbuffer, and you can read it later. Take a look at this article for full details.
这篇关于中断处理程序中的printk，真的有那么糟糕吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！