Linuxカーネルが1500万行を超えるコードなのはなぜですか？[閉まっている]

このモノリシックコードベースの内容は何ですか？

プロセッサアーキテクチャのサポート、セキュリティ、および仮想化は理解していますが、60万行を超えることは想像できません。

カーネルコードベースにドライバーが含まれている歴史的および現在の理由は何ですか？

これらの1500万本以上のラインには、これまでにあらゆるハードウェアのすべての単一ドライバーが含まれていますか？もしそうなら、それは質問を頼みます、なぜドライバーがカーネルに埋め込まれ、自動検出され、ハードウェアIDからインストールされる個別のパッケージではないのですか？

コードベースのサイズは、ストレージが制限されたデバイスまたはメモリが制限されたデバイスの問題ですか？

すべてが埋め込まれている場合、スペースに制約のあるARMデバイスのカーネルサイズが大きくなるようです。プリプロセッサによって多くの行が選択されていますか？クレイジーと呼びますが、カーネルの役割であると理解していることを実行するためにそれほど多くのロジックを必要とするマシンを想像することはできません。

サイズが成長し続けているように見えるため、50年以上後にサイズが問題になるという証拠はありますか？

ドライバーを含めることは、ハードウェアが作成されるにつれて大きくなることを意味します。

編集：これはカーネルの性質であると考えている人にとっては、いくつかの研究の後、それは常にではないことに気づきました。カーネギーメロンのマイクロカーネルマッハは「通常10,000行未満のコード」の例としてリストされているため、カーネルはこれほど大きくする必要はありません。

ドライバーはカーネル内で維持されるため、カーネルの変更が機能のすべてのユーザーに対してグローバルな検索と置換（または検索と手動の変更）を必要とする場合、変更を行う人によって行われます。APIを変更する人がドライバーを更新することは、最新のカーネルでコンパイルしないときに自分で行うのではなく、非常に優れた利点です。

別の方法（ツリー外で保守されたドライバーで発生すること）は、変更に対応するためにメンテナーがパッチを再同期する必要があることです。

クイック検索により、ツリー内ドライバー開発とツリー外ドライバー開発についての議論が始まりました。

Linuxのメンテナンス方法は、主にすべてをメインラインリポジトリに保持することです。#ifdefs を制御するための設定オプションにより、小型のカーネルの構築がサポートされています。そのため、リポジトリ全体でコードのごく一部のみをコンパイルする、小型のカーネルを完全にビルドできます。

組み込みシステムでのLinuxの広範な使用により、カーネルソースツリーが小さい数年前のLinuxに比べて、リソースを除外するためのサポートが向上しました。超最小4.0カーネルは、おそらく超最小2.4.0カーネルよりも小さいでしょう。

3.13に対して実行されたclocによると、Linuxは約1200万行のコードです。

• ドライバーで700万LOC /
• アーチ内に200万LOC /
• カーネル内の139のLOCのみ/

lsmod | wc 私のDebianラップトップでは、実行時に158個のモジュールがロードされるので、モジュールを動的にロードすることはハードウェアをサポートするためのよく使用される方法です。

堅牢な構成システム（例：）をmake menuconfig使用して、コンパイルするコードを選択します（さらに重要なのは、どのコードをコンパイルしないか）。組み込みシステムは、関心の.configあるハードウェアサポートだけで独自のファイルを定義します（カーネルに組み込まれたハードウェアのサポート、またはロード可能なモジュールとしてのサポートを含む）。

興味のある方は、GitHubミラーの行数の内訳をご覧ください。

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

drivers行数の多くに貢献しています。

これまでの答えは「はい、たくさんのコードがあります」と思われ、最も論理的な答えである15M +で質問に取り組んでいる人はいません。だから何？1500万行のソースコードは魚の価格と何の関係がありますか？なぜこれが想像を絶するのですか？

Linuxは明らかに多くのことを行います。何よりも...しかし、あなたのポイントのいくつかは、それが構築され使用されたときに何が起こっているかを尊重しないことを示しています。

• すべてがコンパイルされるわけではありません。カーネルビルドシステムを使用すると、ソースコードのセットを選択する構成をすばやく定義できます。実験的なものもあれば、古いものもあれば、すべてのシステムに必要ではないものもあります。見/boot/config-$(uname -r)に（Ubuntuの上）make menuconfig、あなたは除外されてどれだけ表示されます。

  そして、それは可変ターゲットのデスクトップ配布です。組み込みシステムの構成は、必要なものだけを取り込みます。

• すべてが組み込まれているわけではありません。私の構成では、カーネル機能のほとんどはモジュールとして構築されています。

  grep -c '=m' /boot/config-`uname -r`  # 4078
  grep -c '=y' /boot/config-`uname -r`  # 1944
  

  明確にするために、これらはすべて組み込み可能です...それらを印刷して巨大な紙のサンドイッチにすることができるように。個別のハードウェアジョブのカスタムビルドを実行していない限り、意味がありません（この場合、これらのアイテムの数は既に制限されています）。

• モジュールは動的にロードされます。システムで使用可能なモジュールが数千ある場合でも、必要なものだけをロードできます。次の出力を比較します。

  find /lib/modules/$(uname -r)/ -iname '*.ko' | wc -l  # 4291
  lsmod | wc -l                                         # 99
  

  ほとんど何もロードされません。

• マイクロカーネルは同じものではありません。つながる画像を見ているだけで10秒Wikipediaのページあなたがリンクは、彼らは完全に異なる方法で設計されているハイライトでしょう。

  

  Linuxドライバーは、ユーザースペースではなく、内部的に（大部分は動的にロードされるモジュールとして）組み込まれ、ファイルシステムも同様に内部です。外部ドライバーを使用するよりも悪いのはなぜですか？マイクロが汎用コンピューティングに適しているのはなぜですか？

コメントは、あなたがそれを得ていないことを再び強調しています。Linuxを個別のハードウェア（航空宇宙、TiVo、タブレットなど）に展開する場合は、必要なドライバーのみをビルドするように構成します。デスクトップでも同じことができますmake localmodconfig。最終的に、柔軟性のない小さな目的のカーネルビルドができます。

Ubuntuのようなディストリビューションでは、単一の40MBカーネルパッケージが許容されます。いいえ、スクラブ、4000以上のフローティングモジュールをパッケージとして保持するという大規模なアーカイブおよびダウンロードのシナリオよりも実際に望ましいです。使用するディスク容量が少なく、コンパイル時のパッケージ化が容易で、保存が簡単で、ユーザー（動作するシステムを持っているユーザー）に適しています。

将来も問題ではないようです。CPU速度、ディスク密度/価格、および帯域幅の改善率は、カーネルの成長よりもはるかに速いようです。10年後の200MBカーネルパッケージは、世界の終わりではありません。

また、一方通行ではありません。コードが維持されていないと、コードは追い出されます。

tinyconfigバブルグラフ svg（フィドル）

シェルスクリプトは一緒に使用、カーネルのビルドからJSONを作成するhttp://bl.ocks.org/mbostock/4063269

編集：unifdefいくつかの制限があることが判明しました（-I無視され、-includeサポートされていません。後者は生成された構成ヘッダーを含めるために使用されます）cat。

274692 total # (was 274686)

スクリプトと手順が更新されました。

ドライバー、アーチなどのほかに、選択された構成に依存するかどうかに関係なく、多くの条件付きコードがコンパイルされます。コードは必ずしも動的にロードされるモジュールではなく、コアに組み込まれます。

だから、linux-4.1.6ソースをダウンロードし、tinyconfigを選択し、モジュールを有効にせず、それを有効にするか、実行時にユーザーがそれで何ができるかを正直に知りません、とにかく、カーネルを設定します：

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

カーネルを構築しました

time make V=1 # (should be fast)
#1049168 ./vmlinux (I'm using x86-32 on other arch the size may be different)

カーネルビルドプロセス*.cmdは、.oファイルをビルドし、それらのファイルを処理し、script.sh以下のターゲットおよび依存関係コピーを抽出し、findで使用するために使用されるコマンドラインで呼び出された隠しファイルを残します。

find -name "*.cmd" -exec sh script.sh "{}" \;

これは、ターゲットの各依存のためのコピーを作成.oという名前を.o.c

.cコード

find -name "*.o.c" | grep -v "/scripts/" | xargs wc -l | sort -n
...
   8285 ./kernel/sched/fair.o.c
   8381 ./kernel/sched/core.o.c
   9083 ./kernel/events/core.o.c
 274692 total

.hヘッダー（サニタイズ）

make headers_install INSTALL_HDR_PATH=/tmp/test-hdr
find /tmp/test-hdr/ -name "*.h" | xargs wc -l
...
  1401 /tmp/test-hdr/include/linux/ethtool.h
  2195 /tmp/test-hdr/include/linux/videodev2.h
  4588 /tmp/test-hdr/include/linux/nl80211.h
112445 total

モノリシックカーネルのトレードオフは、当初から公共の場でTananbaumとTorvaldsの間で議論されていました。すべてのためにユーザー空間にアクセスする必要がない場合は、カーネルへのインターフェースをよりシンプルにすることができます。カーネルがモノリシックの場合、内部でより最適化（そしてより複雑に！）できます。

かなり長い間、妥協案としてモジュールがありました。そして、DPDK（カーネルからより多くのネットワーク機能を削除）のようなことを続けています。コアを追加するほど、ロックを回避することが重要になります。より多くのものがユーザー空間に移動し、カーネルが縮小します。

モノリシックカーネルだけがソリューションではないことに注意してください。一部のアーキテクチャでは、カーネル/ユーザー空間の境界は他のどの関数呼び出しよりも高くないため、マイクロカーネルが魅力的です。