誰もが割り込みハンドラができるだけ短いことを知っています。割り込みハンドラ内でのデバッグのためにprintkのような関数を追加することは、実行すべきではないことです。 実際には、私が書いた割り込み駆動のcharデバイスのためにLinuxカーネルをデバッグしていたときにそれを試してみました。ドライバのタイミングが壊れました。割り込みハンドラの中にprintkがありますが、それは本当に悪いですか？
私が持っている質問は、なぜこれが起こっているのでしょうか？ printk機能がバッファされています！つまり、データがキューに挿入され、後で処理されていることを理解している限り、おそらく割り込みハンドラが終了したことを意味します。
なぜそれが機能しませんか？
printk機能がキュー/バッファに挿入されているだけではありません。ログレベルが十分に高いと仮定すると、printkからの出力は、printkの呼び出しの一部としてすぐにコンソールに出力されます。コンソールが、例えば、シリアルポート上にある場合、これは特に遅いです。しかし、どんな場合でも、printkはかなりのオーバーヘッドを導入し、タイミングに影響する可能性があります。
デバッグ出力を取得するタイミングが重要な場所にある場合は、最新のカーネルでtrace_printk関数を使用して調べることができます。これは実際に入力をトレースリングバッファに入れるだけで、後で読むことができます。詳細はthis articleをご覧ください。
trace_printkの代わりにdebugfsはどうですか？それは十分に良いのですか、それとも何か警告がありますか？ – user31986
はい、非常に悪いです。printfはおそらく再入可能ではないためです。何が起こるかは、メインプログラムがprintfを呼び出し、printfが実行されている間に割り込みが到着し、次にIRQハンドラがprintfを呼び出すということです：非常に悪いことが起こります（デッドロック、内部バッファなどの破損など）
あなたの印刷呼び出しがバッファをいっぱいにして、それを強制的にフラッシュする可能性を考慮してください。割り込みハンドラでI/Oを実行するとどうなりますか？ –
はい、本当に悪いです。ありがとう、おやすみなさい。 –
※動作します。 'printk'は割り込みやプロセスコンテキストから呼び出されるように設計されています。そうでなければ、デバッグにあまり役に立たないでしょう。しかし、あなたは明らかにそれを生産ドライバの割り込みコンテキストで呼び出さない。 – EML