記事ディレクトリ
概要
注: init进程和init程序（linuxrc程序）是有区别的。init プロセスは最初から存在し、カーネル状態で実行され、カーネル スレッドに属します。その後、init プロセスがルート ファイル システムをマウントし、アプリケーション init プログラムを実行した後、init プロセスはカーネル状態からユーザー状態に変わります。変換処理中もプロセス番号は変わらずプロセス1のままなので、initプログラム(linuxrcプログラム)をプロセス1とみなす人もいるでしょう。しかし実際には、後の init プログラムに加えて、init プロセスにはカーネル モードでのルート ファイル システムのマウントなどの操作も含まれています。
init プロセスはカーネル モードからユーザー モードへの移行を完了します。
上の図から、Init は最初にカーネル空間から実行され、次にユーザー空間に切り替えて実行されることがわかります。
(1) プロセスには 2 つの状態が連続する
init プロセスは、最初に実行を開始したとき、カーネル スレッドに属するカーネル状態にありましたが、ユーザー状態でプログラムを実行した後、強制的にユーザー状態に変換されます (次のプロセスは、カーネル スレッドで動作する必要があります)。ユーザー状態)。
init プロセスはカーネル モードからユーザー モードへの移行を完了するため、後続の他のプロセスはユーザー モードで動作できるようになります。
(2) カーネルモードのinitプロセスの動作内容
主要是挂载根文件系统，并试图找到用户态下的那个init程序。(この文は、init プロセスが init プログラムよりも先に実行されることを示しています。)
init プロセスは、自身をユーザー モードに変換する場合、アプリケーション プログラムをユーザー モードで実行する必要があります。このアプリケーション プログラムを実行するには、このアプリケーション プログラムを見つける必要があります。このアプリケーション プログラムを見つけるには、ルート ファイル システムをマウントする必要があります。アプリケーション プログラムはすべてファイル システム内にあります。
カーネル ソース コード内のすべての関数はカーネル状態にあり、それらのいずれもカーネル状態から実行することはできません。アプリケーション プログラムがユーザー モードであることを保証するために、アプリケーション プログラムはカーネル ソース コードに属してはなりません。ここで実行される init プログラムはカーネルと一緒ではなく、ルート ファイル システムによって別途提供されます。
(3) ユーザーモードのinitプロセスの作業内容
init プロセスの意味のある作業のほとんどはユーザー モードで実行されます。
オペレーティング システムにとっての init プロセスの重要性は次のとおりです。
他のすべてのユーザー プロセスは、init プロセスから直接的または間接的に派生します。
。
(4) init プロセスはどのようにしてカーネル モードからユーザー モードに移行しますか? 戻ってきてもらえますか？
init进程处于内核态时，通过函数kernel_execve来执行一个用户空间编译链接的应用程序就跳跃到用户态了。
- ジャンプ中にプロセス番号は変化せず、常にプロセス 1 になります。
- ジャンププロセスは一方向であり、init プログラムが実行されてユーザーモードに移行すると、オペレーティングシステム全体が実際に実行され、それ以降はユーザーモードでのみ動作します。ユーザーモードでは、API のみを呼び出すことができます。
- ジャンプ プロセスは
单向はいです。init プログラムが実行されてユーザー モードに移行すると、オペレーティング システム全体が実際に実行され、将来的にはユーザー モードでのみ動作します。ユーザーモードでは、API のみを呼び出すことができます。
1. init プロセスはルート ファイル システムをマウントします。
(1) prepare_namespace 関数は、ルート ファイル システムをマウントします。
(2) ルートファイルシステムはどこにありますか? ルートファイルシステムのファイルシステムタイプは何ですか?
Uboot はパラメーターを渡すことでこの情報をカーネルに伝えます。
uboot パラメータの root=/dev/mmcblk0p2 rw という文は、カーネルにルート ファイル システムの場所を通知します。
uboot パラメータの rootfstype=ext3 という文は、rootfs のタイプをカーネルに伝えるものです。
(3) マウント結果
カーネルがルート ファイル システムを正常にマウントすると、次のように出力されます。 VFS: デバイス 179:2 にルート (ext3 ファイル システム) がマウントされました。(他の数値も可能です)
ルート ファイル システムのマウントに失敗した場合は、次のように出力されます: No filesystem Could mount root, Tryed: yaffs2
(4) カーネルの起動時に rootfs のマウントに失敗した場合、後で実行することはできません。
カーネルは起動失敗後に 5 秒の中断後に自動的に再起動する仕組みを設定しているため、ここで自動的に再起動されるため、再起動が繰り返される場合があります。
(5) rootfs のマウントに失敗する場合は、次の原因が考えられます。
最も一般的な間違いは、uboot の bootargs が正しく設定されていないことです。
Rootfs の書き込みに失敗しました (fastboot の書き込みは間違いやすいものです)。
Rootfs 自体は作成に失敗します。
2. init プロセスは init プログラムを実行して、カーネル状態からユーザー状態への移行を完了します。
(1) rootfs が正常にマウントされたら、rootfs に入ってアプリケーションの init プログラムを検索し (init_post() 関数内)、検索後 run_init_process を使用して実行します。
(2) init プログラムが誰であるかを特定したら?
まず、uboot パラメータの cmdline から指定されているかどうかを確認し、指定されている場合は、cmdline で指定されたプログラムを先に実行します。たとえば、init=/linuxrc は、rootfs のルート ディレクトリにある linuxrc プログラムが init プログラムであることを意味します。
uboot パラメーターの cmdline に init=xx がない場合、または cmdline で指定された xx の実行が失敗した場合には、バックアップ解決策があります。最初のバックアップ: /sbin/init、2 回目のバックアップ: /etc/init、3 回目のバックアップ: /bin/init、4 回目のバックアップ: /bin/sh。上記のいずれも成功しない場合は、他に方法はありません。
init=/linuxrc は通常、busybox を指します。
3. init プロセスはユーザー インターフェイスを構築します
(1) init プロセスは他のユーザー プロセスの祖先です。
Linux システムでのプロセスの作成は、その親プロセスを通じて作成されます。この理論によれば、親プロセスが 1 つ存在する限り、多数の子孫プロセスが誕生する可能性があります。
(2) init は、ログインプロセス (ユーザーログインプロセス)、コマンドラインプロセス (コマンドライン環境を提供)、シェルプロセス (コマンド解釈と実行を提供) を開始します。
(3) シェルプロセスは他のユーザープロセスを起動します。
コマンド ラインとシェルが機能すると、ユーザーはコマンド ラインで ./xx メソッドを使用して他のアプリケーションを実行でき、各アプリケーションの操作はプロセスとなります。
4. init プロセスによりコンソールが開きます。
(1) Linux システムの各プロセスには独自のファイル記述子テーブルがあり、プロセスによって開かれたファイルが格納されます。
(2) Linux システム内のすべてはファイルであるため、デバイスもファイルとしてアクセスされます。デバイスにアクセスするには、そのデバイスに対応するファイル記述子を開く必要があります。たとえば、デバイス ファイル /dev/fb0 は LCD ディスプレイ デバイスを表し、/dev/buzzer はブザー デバイスを表し、/dev/console はコンソール デバイスを表します。
(3) ここでは/dev/consoleファイルを開き、ファイルディスクリプタを2回コピーし、合計3つのファイルディスクリプタを取得します。これら 3 つのファイル記述子は 0、1、2 であり、いわゆる標準入力、標準出力、および標準エラーです。
(4) プロセス 1 はこれら 3 つのファイル記述子をオープンするため、プロセス 1 から派生したすべてのプロセスはデフォルトでこれら 3 つのファイル記述子を持ちます。