printk внутри обработчика прерываний, это действительно так плохо?

Question

все знают, что обработчик прерываний должен быть максимально коротким. и добавление таких функций, как printk для отладки внутри обработчика прерываний, не должно выполняться. На самом деле, я пытался сделать это раньше, когда отлаживал ядро ​​linux для устройства с прерыванием, которое я написал, и это нарушило синхронизацию драйвера.

У меня вопрос, почему это происходит? printk функция буферизована! это означает, насколько я понимаю, что данные вставляются в очередь и обрабатываются позже, скорее всего, после завершения обработки прерывания.

Так почему же это не работает?

Answer 1

Функция printk не просто вставляется в очередь / буфер - при условии, что уровень журнала достаточно высок, вывод из printk будет немедленно отправлен на консоль, как часть вызова printk,Это особенно медленно, если консоль, скажем, на последовательном порту.Но в любом случае, printk вносит довольно существенные издержки и может повлиять на время.

Если у вас есть критическое по времени место, где вы хотите получить отладочный вывод, вы можете посмотреть с помощью функции trace_printkв современных ядрах.Это на самом деле просто помещает ввод в кольцевой буфер трассировки, и вы можете прочитать его позже.Взгляните на эту статью для получения полной информации.

Answer 2

Да, это очень плохо, так как printf, скорее всего, не возвращается. Может случиться так, что основная программа вызывает printf, прерывание приходит во время выполнения printf, а затем обработчик IRQ снова вызывает printf: могут произойти очень плохие вещи (например, тупик, поврежденные внутренние буферы и т. Д.)