IO をブロックする場合、たとえばドライバーの読み取りの場合、何らかの条件で wait_event_interruptible() を呼び出します。条件が満たされた場合、読み取りが行われます。wait_event_interruptible() 関数を調べたところ、状態をチェックして schedule() を呼び出します。schedule() は次の実行可能なプロセスを探し、コンテキスト スイッチを実行し、他のプロセスが実行されます。このプロセスが再び起動されたときに、現在のプロセスに対して実行される次の命令が schedule() 関数内にあるということですか?
はいの場合、複数のプロセスが自発的にスケジュールを呼び出す場合、すべてのプロセスは、起動後に一度実行される次の命令を持ち、スケジュール()内にありますか?
ret_from_interrupt の場合は、schedule() が呼び出されます。いつ戻るの？その後 iret が実行されます。
最初の質問に対する答えはyes、それがコンテキストスイッチングを実装するかなり典型的な方法であるためだと思います。たとえば、OS161はこのように機能します。
スケジューラがISRから呼び出される場合、すべてが同じである必要があります。スケジューラはコンテキストを変更してISRに戻り、ISRはを使用して戻る必要がありIRETます。スケジューラーが別のプロセス/スレッドに切り替えることを選択した場合、別のプロセス/スレッドに戻るため、そのコンテキストをロードして古いものを保存します。
ポイント 2 について:iret命令 (割り込みハンドラからの戻り) が実行され、ret_from_interrupt. 次に、Linux は制御を次に実行するタスクに渡します ( schedule())。割り込みハンドラーを作成する際の最優先事項の 1 つは、割り込みハンドラーの実行中は他の多くのアクティビティが禁止されるため (その他の優先度の低い割り込みが主な例です)、できるだけ早くそこから抜け出したいということです。そのため、ほとんどの割り込みハンドラーは、戻る前に実行する作業を隠しておき、その作業は別の場所 (今日では特別なカーネル スレッド) で処理されます。