私はWebを精査しましたが、「request_threaded_irq」機能に関して、私が持っているいくつかの関連する質問に対する説得力のある答えを見つけられませんでした。
質問1: 最初に、スレッド化されたIRQに関して、この記事を読んでいました。
http://lwn.net/Articles/302043/
そして、私にははっきりしないこの一行があります:
「割り込みをスレッドに変換することは、ハンドラーコードがtasklet / softirq機能を統合し、ロックを単純化することによって割り込みを利用する場合にのみ意味があります。」
「従来の」上半分/下半分のアプローチを進めていたら、共有データに干渉するためにスピンロックまたはローカルIRQを無効にする必要があったことを理解しています。しかし、私が理解していないのは、スレッド化された割り込みが、tasklet / softirq機能を統合することによって、ロックの必要性をどのように単純化するかということです。
質問2: 次に、request_threaded_handlerアプローチはwork_queueベースの下半分のアプローチよりも優れていますか?どちらの場合も、「作業」は専用のスレッドに延期されているように見えます。それで、違いは何ですか?
質問3: 最後に、次のプロトタイプで:
int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long irqflags, const char *devname, void *dev_id)
IRQの「ハンドラ」部分が関連するIRQ(たとえばUARTが高速で文字を受信する)によって継続的にトリガーされる可能性はありますか?割り込みハンドラは、以前のウェイクアップからのIRQの処理でビジーですか?それで、ハンドラーはすでに実行中の「thread_fn」を「ウェイクアップ」しようとしているのではないでしょうか。その場合、実行中のirq thread_fnはどのように動作しますか?
誰かが私がこれを理解するのを手伝ってくれるなら、私は本当に感謝します。
ありがとう、vj