なぜLinuxカーネルは1500万行以上のコードなのですか？
このモノリシックコードベースの内容は何ですか？
プロセッサアーキテクチャのサポート、セキュリティ、仮想化については理解していますが、それが600,000行を超えるとは思えません。
ドライバがカーネルコードベースに含まれている歴史的および現在の理由は何ですか？
これらの1500万行には、これまでのすべてのハードウェアのすべてのドライバーが含まれていますか？もしそうなら、それは疑問を投げかけます、なぜドライバーはカーネルに埋め込まれていて、自動検出されてハードウェアIDからインストールされる個別のパッケージではないのですか？
コードベースのサイズは、ストレージが制限されたデバイスまたはメモリが制限されたデバイスの問題ですか？
スペースに制約があるARMデバイスがすべて埋め込まれている場合、カーネルサイズが膨らむようです。プリプロセッサによって多くの行が間引かれていますか？私が理解していることを実行するためにそのような多くのロジックを必要とするマシンはカーネルの役割です。
一見ますます拡大している性質のため、サイズが50年以上後に問題になるという証拠はありますか？
ドライバを含めることは、ハードウェアが作られるにつれて成長することを意味します。
[〜＃〜] edit [〜＃〜]：これがカーネルの性質であると考える人のために、いくつかの調査の結果、常にではないことに気付きました。 Carnegie Mellonの microkernel Machが「通常は10,000行未満のコード」の例としてリストされているため、カーネルはこれほど大きいものである必要はありません。
ドライバーはカーネル内で維持されるため、カーネルの変更で関数のすべてのユーザーに対してグローバルな検索と置換（または検索と手動の変更）が必要な場合、変更を行った人がそれを実行します。 APIを変更する人がドライバーを更新することは、最新のカーネルでコンパイルされないときに自分で行う必要がなく、非常に優れた利点です。
代替策（ツリー外で維持されているドライバーで発生すること）は、変更に対応するために、メンテナーがパッチを再同期する必要があることです。
クイック検索が表示されました ツリー内とツリー外の論争 ドライバーの開発。
Linuxのメンテナンス方法は、主にすべてをメインラインリポジトリに保持することです。ストリップされた小さなカーネルの構築は、#ifdefs。したがって、リポジトリ全体でコードのごく一部のみをコンパイルする、ストリップされた小さなカーネルを完全に構築できます。
組み込みシステムでのLinuxの広範な使用により、カーネルソースツリーが小さくなった数年前のLinuxよりも、betterのサポートが強化されました。超最小4.0カーネルは、超最小2.4.0カーネルよりもおそらく小さいでしょう。
cloc 3.13に対して実行すると、Linuxは約1200万行のコードです。
- ドライバーの700万LOC /
- Archに200万のLOC /
- カーネル内の139千LOCのみ/
Debianラップトップのlsmod | wcは、実行時に読み込まれる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は、行数のlotに寄与します。
これまでの答えは「はい、コードはたくさんあります」のようで、誰も最も論理的な答えで質問に取り組んでいません：15M +？ SO WHAT？15M行のソースコードは何に関係しますか魚の値段これが想像を絶するものは何ですか？
Linuxは明らかに多くのことを行います。何よりもたくさん...しかし、いくつかのポイントは、ビルドして使用したときに何が起こっているかを尊重していないことを示しています。
すべてがコンパイルされるわけではありません。カーネルビルドシステムを使用すると、ソースコードのセットを選択する構成をすばやく定義できます。実験的なものもあれば、古いものもあれば、すべてのシステムに必要なわけではないものもあります。 _
make menuconfig_の/boot/config-$(uname -r)（Ubuntu）を見ると、どれだけ除外されているかがわかります。そして、それは可変ターゲットのデスクトップディストリビューションです。組み込みシステムの構成は、必要なものだけを取り込みます。
すべてが組み込まれているわけではありません。私の構成では、ほとんどのカーネル機能がモジュールとして組み込まれています。
_
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_何もロードされていません。
マイクロカーネルは同じものではありません。Wikipediaページの先頭の画像を10秒だけ見てください） linked それらは完全に異なる方法で設計されていることを強調します。
![]()
Linuxドライバーはユーザー空間ではなく、内部化され（ほとんどが動的にロードされるモジュールとして）、ファイルシステムも同様に内部化されています。なぜそれが外部ドライバを使用するよりも悪いのですか？マイクロが汎用コンピューティングに適しているのはなぜですか？
コメントは再びあなたがそれを得ていないことを強調しています。 Linuxを個別のハードウェア（航空宇宙、TiVo、タブレットなど）に展開する場合必要なドライバのみをビルドするように構成します。 _make localmodconfig_を使用すると、デスクトップでも同じことができます。最終的には、柔軟性のない小さな目的のカーネルビルドになります。
Ubuntuのようなディストリビューションでは、単一の40MBカーネルパッケージで問題ありません。いいえ、それをスクラブしてください。これは、4000以上のフローティングモジュールをパッケージとして保持することになる大規模なアーカイブとダウンロードのシナリオよりも実際に望ましいです。使用するディスク領域が少なく、コンパイル時のパッケージ化が容易で、保存も簡単で、ユーザー（システムが機能するだけのユーザー）にとっては優れています。
将来も問題ではないようです。 CPU速度、ディスク密度/価格、帯域幅の改善率は、カーネルの成長よりもはるかに速いようです。 10年後の200MBカーネルパッケージは、世界の終わりではありません。
また、一方通行ではありません。コードが維持されていないと、コードは追い出されます。
tinyconfigバブルグラフ svg（フィドル）
シェルスクリプト カーネルビルドからjsonを作成するには、 http://bl.ocks.org/mbostock/4063269 を使用します
Edit：unifdefには制限があります（-Iは無視され、-includeサポートされていません。後者は、生成された構成ヘッダーを含めるために使用されます）この時点でcatを使用しても大きな変化はありません。
274692 total # (was 274686)
スクリプトと手順が更新されました。
ドライバー、Archなどのほかに、選択した構成に応じてコンパイルされているかどうかに関係なく、動的に読み込まれるモジュールではなく、コアに組み込まれている多くの条件付きコードがあります。
だから、ダウンロード 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
モノリシックカーネルのトレードオフは、最初からタナンバウムとトーバルズの間で公の場で議論されました。すべてについてユーザー空間にアクセスする必要がない場合は、カーネルへのインターフェースを単純にすることができます。カーネルがモノリシックである場合、内部でより最適化することができます（そしてより厄介です！）。
妥協案としてかなり長い間モジュールを使用してきました。そして、それはDPDK（カーネルからより多くのネットワーク機能を移動する）のようなものを続けています。コアを追加するほど、ロックを回避することが重要になります。したがって、より多くのものがユーザー空間に移動し、カーネルが縮小します。
モノリシックカーネルが唯一のソリューションではないことに注意してください。一部のアーキテクチャでは、カーネル/ユーザースペースの境界は他の関数呼び出しよりも高価ではないため、マイクロカーネルが魅力的です。