Linux カーネルの準備作業を理解する: C 言語とオペレーティング システムについて少し理解する

はじめに: オペレーティングシステム（英語:OperatingSystem、略称:OS）とは、コンピュータのハードウェアおよびソフトウェア資源を管理するシステムソフトウェアであり、コンピュータシステムの中核であり、基礎となるものです。オペレーティング システムは、ビデオ メモリの管理と構成、システム リソースの需要と供給の優先順位の決定、入出力デバイスの制御、ネットワークの操作、ファイル システムの管理などの基本的なタスクを処理する必要があります。オペレーティング システムは、ユーザーがシステムと対話するための操作インターフェイスも提供します。

1. Linux カーネルの準備作業

Linux カーネルを理解するために準備すべき最良の知識ポイント:

C言語を理解する

オペレーティング システムについての知識を少し知っておく

少数の関連アルゴリズムに精通している

コンピュータ アーキテクチャを理解する

Linux カーネルの機能:

Linux カーネル タスク:

1. 技術的な観点から見ると、カーネルはハードウェアとソフトウェアの間の中間層です。その機能は、アプリケーション層のシーケンス要求をハードウェアに渡し、システム内のさまざまなデバイスやコンポーネントをポーリングする最下位ドライバーとして機能することです。

2. アプリケーション レベルから見ると、アプリケーションはハードウェアとは関係がなく、カーネルとのみ関係します。カーネルは、アプリケーションが認識する階層の最下位レベルです。実際の作業では、カーネルが関連する詳細を具体化します。

3. カーネルはリソース管理プログラムです。利用可能な共有リソース (CPU 時間、ディスク容量、ネットワーク接続など) をさまざまなシステム プロセスに割り当てる責任を負います。

4. カーネルはライブラリのようなもので、システム指向のコマンドのセットを提供します。アプリケーションにとって、システム コールは通常の関数を呼び出すのと同じです。

カーネル実装戦略:

1.マイクロカーネル。最も基本的な機能は、中央カーネル (マイクロカーネル) によって実装されます。他のすべての機能は、明確に定義された通信ソケットを通じて中央コアと通信する独立したプロセスに委任されます。

2. マクロ カーネル。サブシステム (ビデオ メモリ管理、ファイル管理、デバイス ドライバーなど) を含むカーネルのすべてのコードは、ファイルにパッケージ化されます。カーネル内のすべての関数は、カーネルの他のすべての部分にアクセスできます。現在、モジュールの動的なロードとアンロード (切断) がサポートされています。 Linux カーネルは、この戦略に基づいて実装されています。

カーネルメカニズムはどこで使用されていますか?

1. プロセス間で通信するため(CPUの仮想メモリ上にアドレス空間が確保され、各プロセスのアドレス空間は完全に独立しており、同時に実行されるプロセス数はCPU数を超えません) 、特定のカーネル メカニズムを使用する必要があります。

2. プロセス間の切り替え (同時に実行されるプロセスの数は CPU の数を超えない) にもカーネル機構を使用する必要があります。

プロセスの切り替えも、FreeRTOS のタスク切り替えと同様に状態を保存し、プロセスをアイドル状態/再開状態にする必要があります。

3. プロセスのスケジュール設定。そのプロセスがどれくらいの時間実行されているかを確認します。

Linux プロセス:

1. 階層構造を使用すると、各プロセスは親プロセスに依存します。カーネルは最初のプロセスとして init プログラムを開始します。このプロセスは、その後のシステム初期化操作を担当します。 init プロセスはプロセス ツリーのルートであり、すべてのプロセスは直接的または間接的にこのプロセスから発生します。

2. pstree コマンドを使用してクエリを実行します。実際、システムの最初のプロセスは init ではなく systemd です (これも混乱のポイントです)

3. システム内の各プロセスには一意の識別子 (ID) があり、ユーザー (または他のプロセス) はその ID を使用してプロセスにアクセスできます。

2. Linux カーネルソースコードのディレクトリ構造

Linux カーネルのソース コードは 3 つの主要な部分で構成されます:

1. カーネル コア コード (第 3 章で説明したさまざまなサブシステムとサブモジュール、および電源管理、Linux 初期化などのその他のサポート サブシステムを含む)。

2. ライブラリ ファイル (Linux カーネルは自己完結型カーネルであるため、つまり、カーネルは他のソフトウェアに依存せず、単独でコンパイルできるため)、ファームウェア コレクションなどのその他の非コア コード。 KVM（仮想マシン技術）など

3. スクリプト、設定ファイル、ヘルプドキュメント、著作権記述、その他の補助ファイルをコンパイルします。

ls コマンドを使用して、カーネル ソース コードの最上階のディレクトリ構造を確認します。具体的な説明は次のとおりです:

include/----カーネル ヘッダー ファイルを外部モジュール (ユーザー空間コードなど) に提供する必要があります。 kernel/----セクション 3.2 で説明されているプロセス スケジューリング サブシステムとプロセス スケジューリングに関連するモジュールを含む、Linux カーネルのコア コード。 mm/----ビデオ メモリ管理サブシステム (セクション 3.3)。 fs/----VFS サブシステム (セクション 3.4)。 net/----ネットワーク デバイス ドライバー (セクション 3.5) を含まないネットワーク サブシステム。 ipc/----IPC (プロセス間通信) サブシステム。 Arch//----arm、x86 などのアーキテクチャ関連のコード。 Arch//mach-----特定のマシン/ボード関連のコード。 Arch//include/asm----アーキテクチャ関連のヘッダー ファイル。 Arch//boot/dts----DeviceTree ファイル。 init/----Linux システムの起動初期化に関連するコード。 block/----ブロックデバイスの階層を提供します。 sound/----オーディオ関連のドライバーおよびサブシステムは、「オーディオ サブシステム」とみなすことができます。 drivers/----デバイス ドライバー (Linuxkernel3.10 では、デバイス ドライバーがコードの 49.4% を占めます)。 lib/----CRC、FIFO、リスト、MD5 など、カーネルで使用する必要があるライブラリ関数を実装します。 crypto/-----暗号化と復号化に関連するライブラリ関数。 security/----セキュリティ機能 (SELinux) を提供します。 virt/----仮想マシン テクノロジ (KVM など) のサポートを提供します。 usr/----initramfs の生成に使用されるコード。ファームウェア/----サードパーティ製デバイスの駆動に使用されるファームウェアを保存します。サンプル/----サンプルコード。 tools/----パフォーマンス分析、セルフテストなどのいくつかの一般的なツール。 Kconfig、Kbuild、M​​akefile、scripts/---カーネルのコンパイルに使用される設定ファイル、スクリプトなど。コピー中----著作権に関する声明。メンテナ ---- メンテナのリスト。クレジット ----Linux への主要な貢献者のリスト。 REPORTING-BUGS----バグ報告マニュアル。ドキュメント、README ----ヘルプ、ドキュメント。

[記事のメリット] 編集者が独自に推奨する Linux カーネル技術交流グループ: [865977150] が個人的に良いと思う学習書籍やビデオ資料をまとめてグループ ファイルに共有しています。必要に応じて追加できます。自分で！ ！ ！グループに参加した最初の 100 名には、699 相当の追加のコア情報パッケージ (ビデオ チュートリアル、電子書籍、実践的なプロジェクトとコードを含む) が提供されます。

3. Linux カーネル アーキテクチャの簡単な分析

図 1 Linux システム階層

前面はユーザー (またはアプリケーション) スペースです。ここでユーザー アプリケーションが実行されます。ユーザー空間の下にはカーネル空間があり、Linux カーネルはここにあります。 GNUUCLibrary (glibc) もここにあります。これは、カーネルに接続するためのシステム コール ソケットを提供し、ユーザー空間アプリケーションとカーネルの間で変換するメカニズムも提供します。カーネル アプリケーションとユーザー スペース アプリケーションは異なる保護されたアドレス スペースを使用するため、これは重要です。各ユーザー空間プロセスは独自の仮想アドレス空間を使用しますが、カーネルは別のアドレス空間を占有します。

Linux カーネルはさらに 3 つの層に定義できます。先頭はシステム コール ソケットで、読み取りや書き込みなどのいくつかの基本機能を実装します。システムコールソケットの下にはカーネルコードがあり、これはアーキテクチャに依存しないカーネルコードとしてより正確に定義できます。このコードは、Linux でサポートされるすべてのプロセッサ アーキテクチャに共通です。このコードの下にはアーキテクチャに依存するコードがあり、一般に BSP (BoardSupportPackage) と呼ばれるものを形成します。このコードは、特定のアーキテクチャのプロセッサおよびプラットフォーム固有のコードとして機能します。

Linux カーネルは、多くの重要なアーキテクチャ特性を実装しています。より高いレベルまたはより低いレベルで、カーネルはサブシステムとして定義されます。 Linux は、これらすべての基本サービスをカーネルに統合しているため、全体として見ることもできます。これは、マイクロカーネルのアーキテクチャとは異なります Linux カーネルの詳細説明

. 前者は、通信、I/O、メモリ、プロセス管理などのいくつかの基本的なサービスを提供します. より具体的なサービスはマイクロカーネル層に挿入されます。 の。各コアには独自の利点がありますが、ここでは説明しません。

時間が経つにつれて、Linux カーネルはビデオ メモリと CPU 使用率の効率が向上し、非常に安定しています。 Linux の最も興味深い点は、このようなサイズと複雑さにも関わらず、優れた移植性を備えていることです。 Linux は、さまざまなアーキテクチャ上の制約や要件を持つ多数のプロセッサおよびプラットフォーム上で実行できるようにコンパイルされています。反例として、Linux は、グラフィックス メモリ管理ユニット (MMU) を備えたプロセッサ上で実行することも、MMU を提供しないプロセッサ上でも実行できることも挙げられます。

Linux カーネルの uClinux ポートは、非 MMU のサポートを提供します。

図 2 Linux カーネル アーキテクチャ

Linux カーネルの主なコンポーネントは、システム コール ソケット、プロセス管理、メモリ管理、仮想ファイル システム、ネットワーク スタック、デバイス ドライバー、およびハードウェア アーキテクチャ関連コードです。

(1) システムコールソケット

SCI 層は、ユーザー空間からカーネルへの関数呼び出しを実行するための個別のメカニズムを提供します。上で説明したように、同じプロセッサ ファミリ内であっても、このソケットはアーキテクチャに依存します。 SCI は、実際には非常に便利な関数呼び出しの多重化および逆多重化サービスです。 SCI の実装は ./linux/kernel にあり、アーキテクチャに依存する部分は ./linux/arch にあります。

(2) プロセス管理###

プロセス管理の焦点はプロセスの実行です。カーネルでは、このようなプロセスはスレッドと呼ばれ、個々のプロセッサの仮想化 (スレッド コード、データ、スタック、CPU レジスタ) を表します。ユーザー空間では、プロセスという用語が一般に使用されますが、Linux 実装では、これら 2 つの概念 (プロセスとスレッド) が区別されません。カーネルは、SCI を介してアプリケーション プログラミング インターフェイス (API) を提供し、新しいプロセス (fork、exec、または PortableOperatingSystemInterface[POSIX] 関数) の作成、プロセスの停止 (kill、exit)、プロセス間の通信と同期 (シグナルまたは then POSIX メカニズム) を行います。 ）。

プロセス管理には、アクティブなプロセス間で CPU を共有する必要性の処理も含まれます。カーネルは、CPU を巡って競合するスレッドの数に関係なく、一定時間内で動作する新しいタイプのスケジューリング アルゴリズムを実装します。これらのアルゴリズムは O(1) スケジューラと呼ばれ、複数のスレッドのスケジュールにかかる時間が 1 つのスレッドのスケジュールにかかる時間と同じであることを意味します。 O(1) スケジューラは、複数のプロセッサ (対称型マルチプロセッサまたは SMP と呼ばれます) もサポートできます。プロセス管理のソース コードは ./linux/kernel にあり、アーキテクチャに依存するソース コードは ./linux/arch にあります。

(3)ビデオメモリ管理

カーネルによって管理されるもう 1 つの重要なリソースはビデオ メモリです。効率を向上させるために、仮想ビデオ メモリがハードウェアによって管理される場合、ビデオ メモリはいわゆるビデオ メモリ ページ形式 (ほとんどのアーキテクチャでは 4KB) に従って管理されます。 Linux には、利用可能なビデオ メモリを管理する方法と、化学的および仮想マッピングに使用されるハードウェア メカニズムが含まれています。ただし、ビデオ メモリ管理では、4KB バッファ以上のものを管理する必要があります。 Linux は、スラブ アロケータなどの 4KB バッファの具体的な表現を提供します。これらのメモリ管理モードは、ベースとして 4KB バッファを使用し、そこから構造を割り当て、どのメモリ ページがいっぱいであるか、どのページが完全に使用されていないか、どのページが空であるかなど、メモリ ページの使用状況を追跡します。これにより、このモードはシステムのニーズに基づいてビデオ メモリの使用量を動的に調整できます。複数のユーザーによるビデオ メモリの使用をサポートするために、利用可能なビデオ メモリが消費される場合があります。このため、Linux カーネルでは、ページをビデオ メモリから移動して C ドライブに配置することができます。ページがビデオ メモリからハード ドライブにスワップされるため、このプロセスはスワッピングと呼ばれます。ビデオ メモリ管理のソース コードは ./linux/mm にあります。

(4)仮想ファイルシステム

仮想ファイル システム (VFS) は、ファイル システムにユニバーサル インターフェイス表現を提供するため、Linux カーネルの非常に便利な機能です。 VFS は、SCI とカーネルによってサポートされるファイル システム間の交換層を提供します (図 4 を参照)。

図 3 Linux ファイル システムの階層

VFS では、オープン、クローズ、読み取り、書き込みなどの関数の一般的な API 表現です。 VFS の下には、下位レベルの機能の実装方法を定義するファイル システム表現があります。これらは、特定のファイル システム (50 個以上) 用のプラグインです。ファイル システムのソース コードは ./linux/fs にあります。ファイル システム層の下にはバッファ キャッシュがあり、(特定のファイル システムとは独立して) ファイル システム層に共通の機能セットを提供します。このキャッシュ層は、データを一定期間保持する (または、後でデータをプリフェッチして、必要なときに利用できるようにする) ことによって、化学装置へのアクセスを最適化します。バッファ キャッシュの下には、特定の化学デバイス用のソケットを実装するデバイス ドライバーがあります。

(5)ネットワークスタック

ネットワーク スタックは、シミュレートされたコントラクト自体の階層構造に従うように設計されています。インターネット プロトコル (IP) は、トランスポート コントラクト (一般に伝送制御コントラクトまたは TCP として知られている) の基礎となるコア ネットワーク層のコントラクトであることを思い出してください。 TCP の内部にはソケット層があり、SCI を通じて呼び出されます。ソケット層はネットワーク サブシステムの標準 API であり、さまざまなネットワーク コントラクトにユーザー ソケットを提供します。生のフレーム アクセスから IP コントラクト データ ユニット (PDU)、TCP およびユーザー データグラム プロトコル (UDP) まで、ソケット層は接続を管理し、さまざまなエンドポイント間でデータを通信するための標準化された方法を提供します。カーネル内のネットワーク ソース コードは ./linux/net にあります。

(6)デバイスドライバー

Linux カーネルのデバイス ドライバーには、特定のハードウェア デバイスを実行できる大量のコードが含まれています。 Linux ソース ツリーにはドライバー サブディレクトリがあり、これは Bluetooth、I2C、シリアルなど、サポートされるさまざまなデバイスとしてさらに定義されます。デバイス ドライバーのコードは ./linux/drivers にあります。

(7) アーキテクチャに依存するコード

Linux は、実行されているアーキテクチャにほとんど依存しませんが、アーキテクチャが適切に動作し、より高い効率を達成するには、考慮する必要がある要素がいくつかあります。 ./linux/arch サブディレクトリは、カーネル ソース コードのアーキテクチャに依存する部分を定義します。これには、さまざまなアーキテクチャ固有のサブディレクトリ (BSP を構成する) が含まれます。一般的なデスクトップ システムでは、x86 ディレクトリが使用されます。各アーキテクチャのサブディレクトリには他の多くのサブディレクトリが含まれており、各サブディレクトリはブート、カーネル、メモリ管理など、カーネルの特定の側面に重点を置いています。このアーキテクチャに依存するコードは、./linux/arch にあります。

Linux カーネルの移植性と効率が十分ではない場合でも、Linux は分類内で定義するのが難しい他の機能も提供します。 Linux は、運用オペレーティング システムおよびオープン ソース ソフトウェアとして、新しい契約とその改善をテストするための優れたプラットフォームです。 Linux は、従来の TCP/IP だけでなく、高速ネットワーク (1 ギガビット イーサネット [GbE] 未満および 10GbE) の拡張機能を含む、幅広いネットワーク プロトコルをサポートしています。 Linux は、TCP よりも多くの中間機能を提供する (トランスポート層契約の後継となる) ストリーム制御送信契約 (SCTP) などの契約もサポートできます。 Linux は動的カーネルでもあり、ソフトウェア コンポーネントの動的な追加または削除をサポートします。これらは動的にロード可能なカーネル モジュールとして知られており、ブート時 (モジュールは現在特定のデバイスに必要です) またはユーザーがいつでもオンデマンドで挿入できます。

Linux の最新の改良点の 1 つは、他のオペレーティング システムのオペレーティング システム (ハイパーバイザーと呼ばれる) として使用できる機能です。最近、カーネルベースの仮想マシン (KVM) と呼ばれるカーネルに変更が加えられました。この変更により、ユーザー空間用の新しいソケットが有効になり、他のオペレーティング システムを KVM 対応カーネル上で実行できるようになります。 Linux の他のインスタンスを実行するだけでなく、Microsoft Windows も仮想化できます。唯一の制限は、基礎となるプロセッサが新しい仮想化命令をサポートする必要があることです。

4. Linux アーキテクチャとカーネル構造の違い

＃＃＃１。 Linux アーキテクチャ (つまり、Linux システムがどのように構成されているか) について尋ねられた場合、右の図を参照して答えることができます。 大きな観点から見ると、Linux アーキテクチャは 2 つの部分に分けることができます。

＃＃＃２。 Linux アーキテクチャがユーザー空間とカーネル空間に分かれている理由:

1) 最近の CPU は通常、さまざまな動作モードを実装しています。

ARM を例に挙げます: ARM は 7 つの動作モードを実装しています。モードが異なると、CPU が実行できる命令やアクセスするレジスタも異なります:

(2) X86 を例に挙げます。X86 は、リング 0 ～ リング 3 の 4 つの異なる権限レベルを実装しています。リング 0 は特権命令を実行し、IO デバイスにアクセスできます。リング 3 には多くの制限があります。

2) したがって、CPU の観点から見ると、Linux はカーネルのセキュリティを保護するためにシステムを 2 つの部分に分割します。 ＃＃＃３。ユーザー空間とカーネル空間は、プログラム実行の 2 つの異なる状態です。ユーザー空間からカーネル空間への転送は、「システム コール」と「ハードウェア割り込み」を通じて完了できます

＃＃＃４． Linux カーネル構造 (LINux アーキテクチャと Linux カーネル構造の違いに注意してください)

5. Linux 主導のプラットフォームのメカニズム

Linux のこれらのプラットフォーム ドライバー メカニズムの従来の device_driver メカニズムと比較すると、非常に重要な利点は、プラットフォーム メカニズムが独自のリソースをカーネルに登録し、カーネルによって均一に管理されることです。このリソースがドライバーで使用される場合、 platform_device を通じて提供されます。標準ソケットを申請して使用します。これにより、ドライバーとリソース管理の独立性が向上しますが、移植性とセキュリティも向上します。以下は、SPI ドライバー階層の概略図です。Linux の SPI バスは、SPI コントローラーから引き出されたバスとして理解できます。

従来のドライバーと同様、プラットフォームのメカニズムも 3 つのステップに分かれています:

1. バス登録段階:

カーネル起動初期化中の main.c ファイル内の Kernel_init()→do_basic_setup()→driver_init()→platform_bus_init()→bus_register(&platform_bus_type) は、プラットフォーム バス (仮想バス、platform_bus) を登録します。

2. 機器ステージの追加:

デバイスを登録するとき、Platform_device_register()→platform_device_add()→(pdev→dev.bus=&platform_bus_type)→device_add() するだけで、デバイスを仮想バス上にハングします。

3. ドライバー登録段階:

Platform_driver_register()→driver_register()→bus_add_driver()→driver_attach()→bus_for_each_dev()、仮想プラットフォームバス上にハングしている各デバイスに対して __driver_attach()→driver_probe_device() を実行し、drv→bus→match() がこのとき、ポインタを介して platform_match→strncmp(pdev→name,drv→name,BUS_ID_SIZE) を実行し、一致した場合は、real_probe を呼び出して(実際には該当デバイスの platform_driver→probe(platform_device) を実行)、実際の検出: テストし、プローブが成功した場合は、デバイスをドライバーにバインドします。

内部からは、プラットフォーム メカニズムが最終的に 3 つの主要な関数、bus_register()、device_add()、および driver_register() を呼び出していることがわかります。

Platform_device 構造体は、一般的なデバイス構造体 structdevicedev、デバイス リソース構造体 structresource*resource、およびデバイス名 constchar*name を含むプラットフォーム構造体デバイスを記述します。 (この名前は前の platform_driver.driveràname と同じである必要があることに注意してください。理由は前に説明します。)

この構造で最も重要なのはリソース構造であり、これがプラットフォーム メカニズムが導入されている理由です。

名前を同じにする理由:

それに記載されているドライバーは、登録時に関数bus_for_each_dev()を呼び出し、仮想プラットフォームバス上にハングしている各デバイスに対して__driver_attach()→driver_probe_device()を実行します。この関数では、devとdrvを実行します。 、 drv->bus->match が指す関数が呼び出されます。 platform_driver_register 関数では、drv->driver.bus=&platform_bus_type であるため、drv->bus->match は platform_bus_type→match となり、これが platform_match 関数です。

は、dev と drv の名前を比較するもので、同じであれば、really_probe() 関数にステップインするため、さらに照合するために自分で作成したプローブ関数にステップインします。したがって、初期化中に dev→name と driver→drv→name を同じ方法で入力する必要があります。

ドライバーの種類が異なると、一致関数も異なります。このプラットフォームのドライバーは、dev と drv の名前を比較します。USB クラス ドライバーの一致を覚えていますか? ProductID と VendorID を比較します。

プラットフォームメカニズムの利点に関する個人的な要約:

1. platform_bus_type タイプのバスを提供し、バス タイプではないこれらの Soc デバイスをこの仮想バスに追加します。その結果、バス・デバイス・ドライバーモデルを普及させることができます。

2. platform_device および platform_driver タイプのデータ構造を提供し、従来のデバイスおよびドライバーのデータ構造をそれらに埋め込みますが、リソース メンバーを追加して、デバイス リソースを動的に転送する OpenFirmware などの新しいブートローダーやカーネルと簡単に統合します。

6、Linux カーネル アーキテクチャ

Linux カーネルはモノリシックであるため、他のタイプのカーネルに比べて最も大きなスペースを占め、最も複雑になります。これは、Linux の初期にかなりの論争を引き起こした設計機能ですが、単一のカーネルに固有の同じ設計上の欠陥が依然としていくつか残っています。

この欠陥に対処するために、Linux カーネル開発者が行ったことの 1 つは、実行時にカーネル モジュールをロード可能およびアンロード可能にすることでした。これは、カーネル機能を動的に追加または削除できることを意味します。これには、カーネルにハードウェア機能を追加するだけでなく、低レベルの仮想化などのサーバー プロセスを実行するためのモジュールも含めることができますが、場合によってはコンピューターを再起動することなく、カーネル全体を置き換えることもできます。

再起動せずに Windows Service Pack にアップグレードできるかどうか想像してみてください...

セブン、カーネルモジュール

Windows に利用可能なドライバーがすべてインストールされており、必要なドライバーだけをオンにする必要がある場合はどうなりますか? これは基本的に Linux のカーネル モジュールが行うことです。ローダブル カーネル モジュール (LKM) とも呼ばれるカーネル モジュールは、利用可能なビデオ メモリをすべて消費することなくカーネルをすべてのハードウェアで動作させ続けるために必要です。

モジュールは通常、デバイス、ファイル システム、システム コールなどの機能を基本カーネルに追加します。 lkm のファイル拡張子は .ko で、通常は /lib/modules ディレクトリに保存されます。モジュールの特性により、起動時に menuconfig コマンドを使用してモジュールをロードまたはロードしないように設定したり、/boot/config ファイルを編集したり、modprobe コマンドを使用してモジュールを動的にロードおよびアンロードしたりすることで、カーネルを簡単にカスタマイズできます。

サードパーティのクローズド ソース モジュールは、Ubuntu などの一部のディストリビューションで利用できますが、そのようなモジュールのソース コードが利用できないため、デフォルトでインストールするのが難しい場合があります。ソフトウェアの開発者 (nVidia、ATI など) はソース コードを提供しませんが、独自のモジュールを構築し、配布に必要な .ko ファイルをコンパイルします。実際、そのようなモジュールはビールのように無料ですが、音声のように無料ではないため、一部のディストリビューションには含まれていません。保守者は、フリーではないソフトウェアを提供することでカーネルを「汚染する」と考えているからです。

カーネルは魔法のようなものではありませんが、コンピュータが正しく機能するためには不可欠です。 Linux カーネルは、カーネル レベルのドライバーが含まれており、多くの機能が「すぐに」動作できるようにするという点で、OSX や Windows とは異なります。ソフトウェアとハ​​ードウェアがどのように連携するのか、またコンピュータの起動に必要なファイルについてさらに詳しく学んでいただければ幸いです。

結論: 興味の力は無限です。興味があれば情熱が生まれ、仕事と興味が結びつけば仕事にも熱意が生まれ、仕事は単なる仕事ではなく一種の楽しみでもあります。

以上がLinux カーネルの準備作業を理解する: C 言語とオペレーティング システムについて少し理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。