Linuxカーネルとその関連アーキテクチャの依存関係を深く解析
Linux kernelが成功した2つの理由:
柔軟なアーキテクチャ設計により、多くのボランティア開発者が開発過程に簡単に参加することができます。
各サブシステム(特に改善が必要なもの)は、良好な拡張性を備えています。
この2つの理由でLinux kernelは絶えず進化し、改善することができます。
階層構造の原則:
the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers. このようなサブシステム間の依存性は、上から下、すなわち図中の上部のサブシステムが下部のサブシステムに依存するだけであり、逆にはだめである。二、カーネルの役割
三、Linuxカーネルの全体アーキテクチャ
中心システムはプロセススケジューラProcess Schedulerであり、SCHED:残りのサブシステムはすべてプロセススケジューラに依存します。残りのサブシステムはプロセスをブロックし、リカバリする必要があるためです。1つのプロセスがハードウェア動作の完了を待つ必要がある場合、対応するサブシステムはこのプロセスをブロックします。このハードウェア動作が完了すると、サブシステムはこのプロセスをリカバリします。このブロックおよびリカバリ動作は、プロセススケジューラの完了に依存します。
上の図の各依存矢印には、次の理由があります。 プロセススケジューラ依存メモリマネージャMemory manager:プロセスが実行を再開する場合は、メモリマネージャによって実行するメモリを割り当てる必要があります。 IPCサブシステムはメモリマネージャに依存する:共有メモリメカニズムはプロセス間通信の方法であり、2つのプロセスを実行して同じ共有メモリ空間を利用して情報伝達を行う。VFSはネットワークインタフェースNetwork Interfaceに依存する:NFSネットワークファイルシステムをサポートする;
VFS依存メモリマネージャ:ramdiskデバイスのサポート
メモリマネージャはVFSに依存します。スワップswappingをサポートするため、一時的に実行しないプロセスをディスク上のスワップパーティションswapにスワップし、保留状態にすることができます。
四、高度モジュール化設計のシステムは、分業協力に有利である。
五、システム中のデータ構造
六、サブシステムアーキテクチャ
スケジューリングポリシーモジュールscheduling policy module:CPUへのアクセス権を取得するプロセスを決定します。スケジューリングポリシーは、すべてのプロセスができるだけ公平にCPUを共有できるようにする必要があります。
アーキテクチャ関連モジュールarchitecture-specific moduleは、特定のアーキテクチャインタフェースチップのハードウェア詳細を遮断するための統一的な抽象インタフェースのセットを設計する。このモジュールはCPUと対話してプロセスをブロックして復元する。これらの操作には、各プロセスが保存する必要があるレジスタおよびステータス情報を取得し、ブロックまたはリカバリ操作を完了するためにアセンブリコードを実行することが含まれる。
アーキテクチャ依存モジュールarchitecture-independent moduleは、スケジューリングポリシーモジュールと対話して次の実行プロセスを決定し、アーキテクチャ関連コードを呼び出してそのプロセスの実行を復元します。さらに、このモジュールは、ブロックされたプロセスのメモリマッピング情報が正しく保存されることを保証するために、メモリマネージャのインタフェースを呼び出します。
システム呼び出しインタフェースモジュールsystem call interfaceは、Linux Kernelがユーザープロセスに明確に露出したリソースにユーザープロセスがアクセスできるようにします。適切な基本的に不変のインタフェース(POSIX規格)のセットを定義することによって、ユーザアプリケーションとLinuxカーネルをデカップリングし、ユーザプロセスがカーネルの変化の影響を受けないようにする。
(3)データ表示
スケジューラは、要素の各アクティブなプロセスtask_を維持するデータ構造を維持します。structインスタンス;このデータ構造には、プロセスをブロックおよびリカバリするための情報だけでなく、追加のカウントおよびステータス情報も含まれます。このデータ構造はkernelレイヤ全体で共通にアクセスできます。
（4）依存関係、データフロー、制御フロー
前述したように、スケジューラはメモリマネージャが提供する機能を呼び出し、実行を再開する必要があるプロセスに適切な物理アドレスを選択する必要があります。そのため、プロセススケジューラサブシステムはメモリ管理サブシステムに依存します。他のカーネルサブシステムがハードウェア要求の完了を待つ必要がある場合、それらはプロセススケジューリングサブシステムに依存してプロセスのブロックとリカバリを行う。この依存性は,関数呼び出しと共有task listデータ構造へのアクセスによって現れる.すべてのカーネルサブシステムは、現在実行中のプロセスを表すデータ構造を読み書きするため、システム全体を貫く双方向のデータストリームを形成します。
OSサービス層は、カーネル層のデータストリームと制御ストリームに加えて、ユーザプロセスに登録タイマのインタフェースを提供する。これにより、スケジューラによるユーザプロセスの制御フローが形成される。通常、スリープ・プロセスを起動する例は、ユーザ・プロセスがいつ起動されるか予知できないため、通常の制御フロー範囲ではない。最後に、スケジューラはCPUと対話してプロセスをブロックし、復元します。これにより、CPUは現在実行中のプロセスを中断し、カーネルが他のプロセスの実行をスケジューリングできるようにします。
2.メモリマネージャMemory Managerアーキテクチャ
（1）目標
メモリ管理モジュールは、プロセスが物理メモリリソースにどのようにアクセスするかを制御します。プロセス仮想メモリとマシン物理メモリとの間のマッピングは、ハードウェアメモリ管理システム(MMU)によって管理される。各プロセスには独自の仮想メモリ領域があるため、2つのプロセスには同じ仮想アドレスがある可能性がありますが、実際には異なる物理メモリ領域で実行されます。MMUはメモリ保護を提供し、2つのプロセスの物理メモリ空間が互いに干渉しないようにする。メモリ管理モジュールはまた、交換をサポートします。一時的に使用しないメモリ・ページをディスク上の交換パーティションに交換します。この技術により、プロセスの仮想アドレス・スペースが物理メモリのサイズより大きくなります。仮想アドレス空間の大きさはマシンワード長によって決定される.
architecture specific moduleは物理メモリにアクセスする仮想インタフェースを提供する。
アーキテクチャ依存モジュールarchitecture independent moduleは、各プロセスのアドレスマッピングおよび仮想メモリ交換を担当します。欠落エラーが発生した場合、どのメモリ・ページがメモリからスワップされるべきかをモジュールが決定します。このメモリ・ページのスワップ選択アルゴリズムはほとんど変更する必要がないため、ここでは独立したポリシー・モジュールは構築されていません。
システム呼び出しインタフェースsystem call interfaceは、ユーザプロセスに厳格なアクセスインタフェース(mallocおよびfree;mmapおよびummap)を提供する。このモジュールでは、プロセスでメモリを割り当てて解放し、メモリマッピングファイルの操作を実行できます。(3)データ表示
メモリ管理は、各プロセスの仮想メモリから物理メモリへのマッピング情報を格納します。このマッピング情報はmm_に格納されるstruct構造インスタンスでは、このインスタンスのポインタは各プロセスのtask_に格納されます。structで。マッピング情報の格納に加えて、メモリマネージャがページを取得および格納する方法に関する情報もデータブロックに格納する必要があります。例えば、実行可能コードは、実行可能ミラーをバックアップストレージとして使用することができる。ただし、動的申請のデータはシステムページにバックアップする必要があります。△これは読めませんでした。