每个人都知道中断处理程序应该尽可能短。并且在中断处理程序中添加诸如printk
调试之类的功能是不应该做的事情。实际上,我之前在为我编写的中断驱动的字符设备调试linux内核时尝试过,它破坏了驱动程序的时序。
我的问题是,为什么会这样?
printk
函数被缓冲!这意味着,据我了解,数据被插入到队列中,并且稍后处理,很可能是在中断处理程序完成之后。
那么为什么它不起作用呢?
每个人都知道中断处理程序应该尽可能短。并且在中断处理程序中添加诸如printk
调试之类的功能是不应该做的事情。实际上,我之前在为我编写的中断驱动的字符设备调试linux内核时尝试过,它破坏了驱动程序的时序。
我的问题是,为什么会这样?
printk
函数被缓冲!这意味着,据我了解,数据被插入到队列中,并且稍后处理,很可能是在中断处理程序完成之后。
那么为什么它不起作用呢?
该printk
函数不仅仅是插入队列/缓冲区——假设日志级别足够高printk
,作为调用的一部分,来自的输出将立即发送到控制台printk
。如果控制台位于串行端口上,这会特别慢。但无论如何,printk
确实会引入相当大的开销并且会影响时序。
如果您想要获得一些调试输出的时间关键位置,您可以查看trace_printk
在现代内核中使用该函数。这实际上只是将输入放入跟踪环缓冲区,您可以稍后阅读。请查看这篇文章以获取完整的详细信息。
是的,这很糟糕,因为printf
很可能是不可重入的。可能发生的情况是主程序调用 printf,在printf
执行时中断到达,然后 IRQ 处理程序printf
再次调用:可能会发生非常糟糕的事情(例如,死锁、损坏的内部缓冲区等)