Linuxは100％オープンソースなので、Linuxの1行ずつの指示に従い、オペレーティングシステムの全体的な動作原理を観察して、オペレーティングシステムの起動方法をよりよく理解できるかどうかを知りたいです。プロセスのロード、タイムスライスのプロセス/追加タスクの管理、ドライバのロード、システムコールの実行、APIによる操作、ドライバのユーザーモードスレッドアクセス、GUI / Xウィンドウシステムの接続、およびドライバ間の対話。
ソースでこれを行うことは可能ですか？つまり、ソースを直線的に追跡することはどのくらい実現可能ですか？線形ですか？
答え1
これは、Michael KjörlingとOPが想像していたよりも難しいと思います。
OPは、CPUジョブをジョブが順次実行される直線、単一のタイムラインとして見ているようです。これらの印象は、Michael Kjörlingによってさらに強調されています。
これは、ミクロレベル（今日のPCには複数のCPUがある）では確かに不完全であり、中間/マクロレベルでは役に立ちません。
我々は、マクロ変数の観点からすべての複雑なシステムを説明します。これは時々これが私たちがアクセスできる変数に過ぎませんが、その有用性は主にアクセス可能であるという点ではありません。すべての関連粒子の位置と速度を記述してガスを説明する代わりに、圧力/体積/温度/エントロピーを使用します。
同様に、CPUコマンドを使用してマシンの状態を特徴付けるのではなく、実行中のジョブとサービスを介してシステムの状態を特徴付けます。したがって、いつでも複数のプロセスが実行され、情報を交換し、共通の目標を達成するために協力的に（残念ながら時には競合することもある）行動することがよくあります。
コンピュータサイエンスの圧力/容積/エントロピー/温度は、タスクを実行するエージェントの実際の実装に関係なく、マシンが実行するタスクを単純化して表現する抽象化レイヤと同じです。 ALは、HALからOSI層まで、コンピュータサイエンス全体に存在します。
コンピュータタスクの段階的表現を必要とすることは、多粒子流体記述を好むことによって乱流理論の歪みアトラクタを放棄することに等しい。あるいは、化学結合を研究して人間のゲノムを解読してみてください。 1つは別のものに基づいて構築されますが、新しい抽象化層は他の方法では想像できない洞察を提供します。
答え2
ソースコードを見て、システムのしくみを理解できます（C / C ++とアセンブリに精通している場合）。私が知っている限り、コードは線形ではありません。
答え3
おそらく得られる最大のものは、オンラインデバッグとsystemdのロギングデーモンです。このデーモンは、非常に初期から（既存のログ記録ツールよりも前に）すべてを記録します。
これで十分ではなく、より低いレベルでシステムを追跡したい場合は、仮想環境（QEMUなど）でLinuxを実行できます。これにより、内部の深い洞察を得ることができ、ライブカーネルでgdbを使用できます。リアルタイムカーネルとフルイメージデバッグ用にQEMUを設定する方法に関するいくつかのチュートリアルがあります。http://www.cs.rochester.edu/~sandhya/csc256/locationments/qemu_linux.html
カーネル内部デバッグツールに関するstackowerflowの質問も参照してください。https://stackoverflow.com/questions/4943857/linux-kernel-live-debugging-how-its-done-and-what-tools-are-used
答え4
私はそれをあなたに指摘したいと思いますbootchart。bootchartinitの代わりに、最初のプロセスで始まり、実行される項目と実行にかかる時間を監視します。
これは監視したいすべてではありませんが、非常に良いグラフィック出力を提供するので、試してみる価値があります。
たとえば、システムコールを監視するには、perf record初期起動時に実行できますが、数百万行を解釈する方法によって異なります。