Warum enthält der Linux-Kernel mehr als 15 Millionen Codezeilen? [geschlossen]

Was ist der Inhalt dieser monolithischen Codebasis?

Ich verstehe die Unterstützung der Prozessorarchitektur, die Sicherheit und die Virtualisierung, kann mir aber nicht vorstellen, dass das mehr als 600.000 Zeilen sind.

Was sind die historischen und aktuellen Gründe, warum Treiber in der Kernel-Codebasis enthalten sind?

Enthalten diese mehr als 15 Millionen Leitungen jeden einzelnen Treiber für jede Hardware? Wenn ja, stellt sich dann die Frage, warum Treiber in den Kernel eingebettet sind und nicht Pakete, die automatisch erkannt und von Hardware-IDs installiert werden?

Ist die Größe der Codebasis ein Problem für Geräte mit eingeschränktem Speicher oder mit eingeschränktem Speicher?

Es scheint, als würde die Kernelgröße für ARM-Geräte mit eingeschränktem Speicherplatz aufgebläht, wenn alles eingebettet wäre. Werden viele Zeilen vom Präprozessor ausgesondert? Nennen Sie mich verrückt, aber ich kann mir nicht vorstellen, dass eine Maschine so viel Logik benötigt, um zu funktionieren. Ich verstehe, dass es sich um die Rollen eines Kernels handelt.

Gibt es Beweise dafür, dass die Größe in mehr als 50 Jahren ein Problem sein wird, da sie anscheinend immer größer wird?

Das Einbeziehen von Treibern bedeutet, dass es mit der Hardware wächst.

EDIT : Für diejenigen, die denken, dass dies die Natur des Kernels ist, wurde mir nach einigen Recherchen klar, dass dies nicht immer der Fall ist. Ein Kernel muss nicht so groß sein, da der Microkernel Mach von Carnegie Mellon als Beispiel aufgeführt wurde: "Normalerweise weniger als 10.000 Codezeilen".

Treiber werden im Kernel verwaltet. Wenn eine Kerneländerung ein globales Suchen und Ersetzen (oder Suchen und Ändern von Hand) für alle Benutzer einer Funktion erfordert, wird dies von der Person durchgeführt, die die Änderung vornimmt. Das Aktualisieren Ihres Treibers durch Benutzer, die API-Änderungen vornehmen, ist ein sehr schöner Vorteil, anstatt dies selbst tun zu müssen, wenn es auf einem neueren Kernel nicht kompiliert werden kann.

Die Alternative (was bei Treibern geschieht, die außerhalb der Baumstruktur gepflegt werden) besteht darin, dass der Patch von den Betreuern erneut synchronisiert werden muss, um mit den Änderungen Schritt zu halten.

Eine schnelle Suche führte zu einer Debatte über die Entwicklung von In-Tree- und Out-of-Tree- Treibern.

Die Art und Weise, wie Linux gewartet wird, besteht hauptsächlich darin, alles im Mainline-Repo zu belassen. Das Erstellen kleiner, reduzierter Kernel wird durch Konfigurationsoptionen zur Steuerung von #ifdefs unterstützt. Sie können also absolut winzige, abgespeckte Kernel erstellen, die im gesamten Repo nur einen winzigen Teil des Codes kompilieren.

Die umfangreiche Verwendung von Linux in eingebetteten Systemen hat zu einer besseren Unterstützung für das Weglassen von Dingen geführt, als Linux dies Jahre zuvor getan hatte, als der Kernel-Quellbaum kleiner war. Ein Super-Minimal-4.0-Kernel ist wahrscheinlich kleiner als ein Super-Minimal-2.4.0-Kernel.

Laut Cloc Run gegen 3.13 besteht Linux aus etwa 12 Millionen Codezeilen.

• 7 Millionen LOC in Fahrern /
• 2 Millionen LOC in Bogen /
• nur 139 Tausend LOC im Kernel /

lsmod | wc Auf meinem Debian-Laptop werden 158 Module zur Laufzeit geladen, so dass das dynamische Laden von Modulen eine häufig verwendete Methode zur Unterstützung von Hardware ist.

Das robuste Konfigurationssystem (z. B. make menuconfig) wird verwendet, um auszuwählen, welcher Code kompiliert werden soll (und mehr zu Ihrem Punkt, welcher Code nicht kompiliert werden soll). Eingebettete Systeme definieren ihre eigene .configDatei mit der Hardware-Unterstützung, die ihnen wichtig ist (einschließlich der Unterstützung der im Kernel integrierten Hardware oder als ladbare Module).

Für alle, die neugierig sind, hier ist die Aufschlüsselung der Zeilenanzahl für den GitHub-Spiegel:

=============================================
    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
=============================================

driversträgt zu einem Großteil der Zeilenanzahl bei.

Die bisherigen Antworten scheinen zu lauten "Ja, es gibt viel Code" und niemand geht die Frage mit der logischsten Antwort an: 15 Millionen +? NA UND? Was haben 15 Millionen Zeilen Quellcode mit dem Preis für Fisch zu tun? Was macht das so unvorstellbar?

Linux leistet eindeutig viel. Viel mehr als alles andere ... Aber einige deiner Punkte zeigen, dass du nicht respektierst, was passiert, wenn es gebaut und benutzt wird.

• Nicht alles ist kompiliert. Mit dem Kernel-Build-System können Sie schnell Konfigurationen definieren, die Sätze von Quellcode auswählen. Manche sind experimentell, manche sind alt, manche werden einfach nicht für jedes System benötigt. Schauen Sie sich /boot/config-$(uname -r)(auf Ubuntu) in an make menuconfigund Sie werden sehen, wie viel davon ausgeschlossen ist.

  Und das ist eine Desktop-Distribution mit variablem Ziel. Die Konfiguration für ein eingebettetes System würde nur die Dinge einbeziehen, die es benötigt.

• Nicht alles ist eingebaut. In meiner Konfiguration sind die meisten Kernel-Funktionen als Module aufgebaut:

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

  Um es klar zu sagen, diese könnten alle eingebaut sein ... Genau wie sie ausgedruckt und zu einem riesigen Papiersandwich verarbeitet werden könnten. Es wäre nur sinnvoll, wenn Sie einen benutzerdefinierten Build für einen diskreten Hardware-Job ausführen würden (in diesem Fall hätten Sie die Anzahl dieser Elemente bereits begrenzt).

• Module werden dynamisch geladen. Selbst wenn einem System Tausende von Modulen zur Verfügung stehen, können Sie mit dem System genau das laden, was Sie benötigen. Vergleichen Sie die Ausgaben von:

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

  Es ist fast nichts geladen.

• Mikrokerne sind nicht dasselbe. Wenn Sie das führende Bild der von Ihnen verlinkten Wikipedia-Seite in nur 10 Sekunden betrachten, wird deutlich, dass sie auf eine völlig andere Art und Weise gestaltet sind.

  

  Linux-Treiber sind internalisiert (meist als dynamisch geladene Module), nicht als Userspace, und die Dateisysteme sind ähnlich intern. Warum ist das schlimmer als mit externen Treibern? Warum ist Mikro besser für Allzweck-Computing?

Die Kommentare heben erneut hervor, dass Sie es nicht verstehen. Wenn Sie Linux auf diskreter Hardware (z. B. Luft- und Raumfahrt, TiVo, Tablet usw.) bereitstellen möchten, konfigurieren Sie es so, dass nur die benötigten Treiber erstellt werden . Sie können dasselbe auf Ihrem Desktop mit tun make localmodconfig. Am Ende haben Sie einen winzigen zweckgebundenen Kernel-Build ohne Flexibilität.

Für Distributionen wie Ubuntu ist ein einzelnes 40-MB-Kernel-Paket akzeptabel. Nein, das ist besser als das massive Archivierungs- und Download-Szenario, bei dem 4000+ Floating-Module als Pakete erhalten bleiben. Es benötigt weniger Speicherplatz für sie, ist einfacher beim Kompilieren zu packen, einfacher zu speichern und ist besser für ihre Benutzer (die ein System haben, das einfach funktioniert).

Auch die Zukunft scheint kein Thema zu sein. Die Geschwindigkeit der CPU-Geschwindigkeit, der Festplattendichte / Preisgestaltung und der Bandbreitenverbesserungen scheint viel schneller zu sein als das Wachstum des Kernels. Ein 200MB Kernel-Paket in 10 Jahren wäre nicht das Ende der Welt.

Es ist auch keine Einbahnstraße. Code wird rausgeschmissen, wenn er nicht gepflegt wird.

tinyconfig bubble graph svg (Geige)

Shell-Skript zum Erstellen des JSON aus dem Kernel-Build unter http://bl.ocks.org/mbostock/4063269

Bearbeiten : stellte sich heraus , unifdefhaben einige Einschränkungen ( -Iwird ignoriert und -includenicht unterstützte, letztere verwendet wird , um die erzeugte Konfigurations - Header enthalten) an dieser Stelle mit catändert sich nicht viel:

274692 total # (was 274686)

Skript und Prozedur aktualisiert.

Neben Treibern, Arch usw. gibt es eine Menge Bedingungscode, der kompiliert oder nicht kompiliert wird, abhängig von der gewählten Konfiguration. Code muss nicht unbedingt in dynamisch geladenen Modulen, sondern im Kern integriert sein.

Also, Linux-4.1.6-Quellen heruntergeladen , tinyconfig ausgewählt , Module nicht aktiviert und ich weiß ehrlich gesagt nicht, was es aktiviert oder was ein Benutzer zur Laufzeit damit machen kann, jedenfalls den Kernel konfigurieren:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

baute den Kernel

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

Der Kernel-Erstellungsprozess lässt versteckte Dateien *.cmdmit der Kommandozeile aufgerufen , die auch zum Erstellen von .oDateien verwendet wird, um diese Dateien zu verarbeiten und Ziel- und Abhängigkeiten zu extrahieren. Kopieren Sie die folgenden Dateien script.shund verwenden Sie sie mit find :

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

Dadurch wird eine Kopie für jede Abhängigkeit des .obenannten Ziels erstellt.o.c

.c Code

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 Header ( bereinigt )

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

Die Kompromisse zwischen monolithischen Kernen wurden von Anfang an öffentlich zwischen Tananbaum und Torvalds diskutiert. Wenn Sie nicht für alles in den Userspace wechseln müssen, ist die Schnittstelle zum Kernel möglicherweise einfacher. Wenn der Kernel monolithisch ist, kann er intern optimiert (und unordentlicher!) Werden.

Wir haben schon seit einiger Zeit Module als Kompromiss. Und es geht weiter mit Dingen wie DPDK (Verschieben von mehr Netzwerkfunktionalität aus dem Kernel). Je mehr Kerne hinzugefügt werden, desto wichtiger ist es, ein Blockieren zu vermeiden. So rücken mehr Dinge in den Benutzerbereich und der Kernel wird kleiner.

Beachten Sie, dass monolithische Kernel nicht die einzige Lösung sind. Auf einigen Architekturen ist die Grenze zwischen Kernel und Benutzerbereich nicht teurer als jeder andere Funktionsaufruf, wodurch Mikrokerne attraktiv werden.