システムプロセス、ユーザープロセス、カーネル制御パス、カーネルスレッドの違い
私の理解は
- プロセスは常にユーザーモードで実行され、ユーザースペースのみを使用します。
- カーネルは常にカーネルモードで実行され、カーネルスペースのみを使用します。
しかし、次の2冊の本を読んだ後、私は正しくないかもしれません。私が間違っていたら訂正してくれませんか。
MaurerによるLinuxカーネルアーキテクチャでは、「システムプロセス」および「ユーザープロセス」という用語は、定義なしで使用されています。たとえば、 仮想アドレス空間をカーネル空間とユーザー空間に分割する場合 ：
システム内のすべてのユーザープロセスには、0からTASK_SIZEまでの独自の仮想アドレス範囲があります。上記の領域（TASK_SIZEから2 32または2 64まで）は、カーネル専用に予約されており、ユーザープロセスからアクセスできない場合があります。 TASK_SIZEは、特定の比率でアドレススペースを分割するアーキテクチャ固有の定数です。たとえば、IA-32システムでは、アドレススペースは3 GiB各プロセスは3 GiBです。1GiBは、仮想アドレス空間の合計サイズが4 GiBであるため、カーネルで使用できます。実際の数値はアーキテクチャによって異なりますが、一般的な概念では違います。Iしたがって、以降の説明ではこれらのサンプル値を使用します。
この分割は、RAMが利用可能な量に依存しません。アドレス空間の仮想化の結果として、各ユーザープロセスは、それが3 GiB個々のシステムプロセスのユーザー空間は互いに完全に分離されており、現在実行中のプロセスに関係なく、仮想アドレス空間の上端のカーネル空間は常に同じです。
...カーネルは仮想アドレス空間を2つの部分に分割し、個々のシステムプロセスを互いに保護できるようにします。
本の「ユーザープロセス」または「システムプロセス」を検索すると、さらに多くの例を読むことができます。
カーネルではなく、ユーザープロセスとシステムプロセスの両方がプロセスですか？
それらの定義は何ですか？それらは、所有者（通常のユーザーまたはroot？）、それらを開始したユーザー、または他の何かによって異なりますか？
たとえば、上記の引用のように、本が両方の種類の「プロセス」をカバーするために、単に「プロセス」ではなく「システムプロセス」または「ユーザープロセス」を明示的に記述するのはなぜですか。 「ユーザープロセス」についても「システムプロセス」にも当てはまり、「システムプロセス」についても「ユーザープロセス」にも当てはまると思います。
BovetによるLinuxカーネルの理解には、「カーネル制御パス」と「カーネルスレッド」という概念があります。
カーネル制御パスは、システムコール、例外、または割り込みを処理するためにカーネルによって実行される命令のシーケンスを示します。
...従来のUnixシステムは、ディスクキャッシュのフラッシュ、未使用のページのスワップアウト、ネットワーク接続のサービスなど、重要なタスクを断続的に実行するプロセスに委任しています。実際、これらのタスクを厳密に直線的に実行することは効率的ではありません。それらの機能とエンドユーザープロセスの両方がバックグラウンドでスケジュールされている場合、応答が向上します。一部のシステムプロセスはカーネルモードでのみ実行されるため、最新のオペレーティングシステムでは、機能がカーネルスレッドに委任されます。不要なユーザーモードコンテキスト。 Linuxでは、カーネルスレッドは次の点で通常のプロセスと異なります。
•カーネルスレッドはカーネルモードでのみ実行されますが、通常のプロセスはカーネルモードとユーザーモードで交互に実行されます。
•カーネルスレッドはカーネルモードでのみ実行されるため、PAGE_OFFSETより大きい線形アドレスのみを使用します。一方、通常のプロセスは、ユーザーモードまたはカーネルモードのいずれかで、4ギガバイトのリニアアドレスをすべて使用します。
詳しくは Googleブックス で検索してください。
Maurerの本とBovetの本の「システムプロセス」は同じ概念ですか？
2冊の本で言及されている「システムプロセス」は、ユーザー空間、カーネル空間、またはその両方で実行できますか？
「システムプロセス」は、カーネル制御パスやカーネルスレッドとは異なりますか？
Linuxの場合、タスク（スレッドのカーネル内部のアイデア。スレッドはメモリや開いているファイルなどのリソースを共有できます。一部はカーネル内部でのみ実行されます）はユーザーランドで実行できます。または（実行のスレッドです）システムコールを実行するカーネル（およびその逆）。ユーザースレッドを一時的にハイジャックして、割り込みを実行することができます（ただし、実際にはそのスレッドは実行されていません）。
プロセスが「システムプロセス」であるか、通常のユーザープロセスがUnixではまったく無関係であるかは、まったく同じように処理されます。 Linuxの場合、いくつかのタスクはカーネル内で実行され、その他のジョブを処理します。ただし、これらは「システムプロセス」ではなく、カーネルジョブです。
1つの大きな警告：複雑なソフトウェア製品のテキスト（コンパイラとオペレーティングシステムは特に悪質な例です）は、単純化したアルゴリズム（多くの場合、実世界のマシンとユーザーの要件はmuchが複雑すぎて、構造化された単純な方法で説明できる何らかの方法で処理できないため、半世紀にわたって本格的に使用されていました。コンパイラーの多くはその場しのぎの調整です（特にコードの最適化の分野では、変換はほとんどの場合、実際の使用で現れる可能性のサブセットです）。 Linuxの場合、ほとんどのコードはデバイスドライバー（オペレーティングシステムのテキストでデバイス依存として言及されている）であり、このコードの大部分は、独自の仕様に準拠していない、または動作しないデバイスを処理しています。 「同じデバイス」のバージョン間で動作が異なります。多くの場合、詳細に説明されているのは、canをいくつかのニース理論に縮小して、乱雑で不規則な部分を（ほとんど）完全に除外したジョブのセグメントだけです。たとえば、 [〜＃〜] lcc [〜＃〜] コンパイラについて説明している本のCris FraserとDavid Hansonは、典型的なコンパイラテキストには字句解析と解析に関する説明がほとんど含まれているが、コード生成。これらのタスクは、（シンプルに設計された！）コンパイラのコードの約5％であり、エラー率はごくわずかです。コンパイラの複雑な部分は、標準テキストではカバーされていません。
Q：カーネルではなく、ユーザープロセスとカーネルプロセスの両方ですか？
正解が1つだけかどうかはわかりませんが、試してみましょう。
「オペレーティングシステムの設計と実装」（A. Tanenbaum）、第3版、第2.1章からの引用：
2.1。プロセスの紹介
最近のコンピュータはすべて、同時にいくつかのことを実行できます。ユーザープログラムを実行している間、コンピューターはディスクから読み取り、テキストを画面またはプリンターに出力することもできます。マルチプログラミングシステムでは、CPUもプログラムからプログラムに切り替わり、それぞれ数十または数百ミリ秒実行されます。厳密に言えば、CPUはいつでも1つのプログラムしか実行していませんが、1秒間で複数のプログラムで動作する可能性があり、ユーザーに並列処理のような錯覚を与えます。このコンテキストで疑似並列処理について話すことがあります。これは、マルチプロセッサシステムの真のハードウェア並列処理（2つ以上のCPUが同じ物理メモリを共有しているシステム）とは対照的です。複数の並行アクティビティを追跡することは、人々にとって困難です。したがって、長年にわたってオペレーティングシステムの設計者は、並列処理を容易にする概念モデル（シーケンシャルプロセス）を進化させてきました。そのモデル、その使用法、およびその結果のいくつかは、この章の主題を形成します。
2.1.1。プロセスモデル
このモデルでは、コンピューター上で実行可能なすべてのソフトウェア（オペレーティングシステムを含む場合があります）は、多数の順次プロセス、または単にプロセスの略で構成されています。 プロセスは、プログラムカウンター、レジスタ、変数の現在の値を含む、実行中のプログラムです。
（強調鉱山）
私はまだ本を読み終えるまでには至っていませんが、この説明によると、「プロセス」はプロセッサで実行される作業の単位であり、必要なすべてのリソース（イメージ、状態、レジスター、カウンターなど）を保持します。
編集された質問への回答
カーネルは常にカーネルモードで実行され、カーネルスペースのみを使用します。
それはカーネルのタイプに依存します。モノリシックカーネルは単一のアドレススペース（カーネルスペース）でその内容を実行しますが、マイクロカーネルはユーザースペースでカーネルプロセスを実行できます。
2冊の本で言及されている「システムプロセス」は、ユーザー空間、カーネル空間、またはその両方で実行できますか？
上記を参照してください。カーネルのタイプによっては、システムプロセスが両方のモードで実行される場合があります。
カーネルではなく、ユーザープロセスとシステムプロセスの両方がプロセスですか？
はい、ユーザープロセスとシステムプロセスはどちらもプロセスです-したがって、名前付け;-)ただし、コンマの後の部分は理解できません。
「システムプロセス」は、カーネル制御パスやカーネルスレッドとは異なりますか？
はい。プロセス（userまたはsystem = kernel）は何か別のものです。
カーネル制御パスは、命令のシーケンスを示します。カーネルスレッド（別名LWP-軽量プロセス）は、カーネルとして直接作成およびスケジュールされるスレッドです（スレッド化libによって作成されるユーザースレッドとは異なります）。
結論
processは単なる理論上の構造です。
Akernelは、プロセスの概念を実装するOSの一部です。たとえば、前記プロセスのスケジューリング。
Athreadは、独立してスケジュールできるプロセスの最小部分です。
Q. Maurerの本とBovetの本の「システムプロセス」は同じ概念ですか？
マウラーの用途 システムプロセス 両方をカバーする総称として ユーザープロセス そして カーネルスレッド。
私が見ることができるものから、Bovetは使用していません システムプロセス Maurerよりも具体的な概念を定義します。彼はそれほど厳格でない言葉を使っているかもしれません。だから私はそれらを直接同一視しないように気をつけます。文章が難しい
一部のシステムプロセスはカーネルモードでのみ実行されるため、最新のオペレーティングシステムはカーネルスレッドにその機能を委任します。カーネルスレッドは、不要なユーザーモードコンテキストに邪魔されません。
だれの機能が委任されていますか？オペレーティングシステムの機能ですか、それともシステムプロセスの機能ですか。システムプロセスはカーネルモードでのみ実行されるため、その機能はカーネルスレッドに委任されると言っても意味がありません。特定のオペレーティングシステム機能をカーネルスレッドに「委任」するオペレーティングシステムについて考えることは、いくらか理にかなっています。ただし、「理由」は、マウラーの定義を使用した場合、実際には意味をなさない システムプロセス。したがって、私はこの文の厳密な意味を無視します。
（そして、「煩わしさ」の欠如はかなり重要ではなく、詳細は特定の実装と矛盾する場合があります）。
妥当なルーズな再解釈は、カーネルがカーネル外での特定の「重要なタスク」の実行をサポートしていないこと、およびこれらのタスクの一部はカーネルスレッドによって処理されることです。
Q. 2冊の本で言及されている「システムプロセス」は、ユーザー空間、カーネル空間、またはその両方で実行できますか？
特定の時点で、システムプロセスはユーザー空間またはカーネル空間で実行できます。
ユーザープロセスがシステムコールを行うと、プロセスはカーネル空間での実行に移行します。システムコールが戻ると、プロセスはユーザー空間での実行に戻ります。
Q.「システムプロセス」は、カーネル制御パスやカーネルスレッドとは異なりますか？
上記の定義に従って、カーネルスレッドはシステムプロセスですが、システムプロセスはカーネルスレッドではない場合があります。
Bovetはspin_lockマクロは、成功すると、現在のカーネルパスにスピンロック（他のカーネルパスを除く）を「取得」させます。 spin_lockはカーネルスレッドから呼び出すことができるため、カーネルスレッドはカーネル制御パスとしてカウントされます。私の知る限り。そして、私が知る限り、これに矛盾はありません。しかし、これが明示的に定義されていないため、カーネル制御パスとは何か、およびそうではないため、この暗黙の定義に依存して、彼がフレーズを使用するすべての場所に適用することはしません。
システムコール、例外、または割り込みのカーネル制御パスは、カーネルスレッドではありません。
ただし、一部のドライバーは、割り込みへの応答の実質的にすべてを処理するためにスレッドを使用するようになりました。 （スレッド外の唯一の部分は、複数のデバイス間で共有される割り込みラインを明確にすることです）。
スレッドへの割り込みの移動 -LWN.net、2008
https://www.kernel.org/doc/html/v4.20/core-api/genericirq.html （「スレッド」を検索）
短くしてください。うまくいけば、ここですべての答えを明確にしてください。最新のLinuxカーネルにのみ適用されます。
struct tasksがあり、カーネルによって内部的に最小スケジュール可能ユニットとして使用されます。これは、常にring0を使用してカーネルコードによって作成され、ring0で実行を開始しますが、後でring3に切り替えたり、リング0に切り替えたりすることができます（プラットフォーム固有のsyscall命令）。
タスクには多くのリソースまたは言うプロパティがあります。最も重要なものは、メモリスペース、タスクid（トップレベルのpidネームスペースから見たtid）、タスクグループid（ネームスペースのトップレベルから見たpid）です。 ring3では、タスクはそれ自体のstruct taskに直接アクセスすることはできませんが、少なくとも前述のプロパティは/procfsを介してカーネルによってring3に公開されます。しかし、現代のkenerlは/proc/[pid]/statusのように奇妙な方法でそれを公開する可能性があります。「Pid」という単語を使用して、procfsインスタンスに関連付けられたpid名前空間から見たタスクIDを参照します。
タスクは、これらのプロパティを他のタスクと共有する場合としない場合があります（最上位のpid名前空間から表示されるtidを除く）。たとえば、まったく同じ1つのメモリ空間を共有する場合や、同じタスクグループIDを持つ場合があります。
これで、ring3のユーザー、つまりユーザースペースは、「スレッド」と「プロセス」の概念を生み出すことができます。しかし、それらは純粋にユーザー空間の発明であるため、異なる人々/教科書は異なる用語を使用する場合があります。したがって、ここでは一般的に使用される用語についてのみ説明します。
OS-Thread（thread）：タスクの同義語。
カーネルスレッド：ring3に切り替えず、常にカーネルとメモリ空間を共有するタスク。
OS-Process（process）：カーネルはプロセスの存在を追跡せず、人間はそれを同じタスクグループID（最上位のpidネームスペースから見たpid）を持つ1つ以上のタスクとして定義します。これらのスレッドがすべて終了すると、プロセスは人間の心から消えました。
重要な面白い事実の1つは、上記の定義から結論付けることができるはずですが、OSプロセスには1つ以上のOSスレッドが含まれている可能性があり、これらのOSスレッド、または言うタスクは、1つのOSプロセスが実際にはそれらができる特性についてのカーネルn share。
タスクが作成されると、そのタスクは特定のプロセスに属し、この関係は、終了するまで変更できません。
1つのプロセスに属するタスクは、まったく同じ1つのメモリ空間を共有する必要があります。
1つのプロセスに属するタスクは、異なるユーザー名前空間またはpid名前空間にとどまることはできません。これらは共有する必要があります。