Zahlen bitte! Linux: mehr als 25 Millionen Zeilen Code

Der Linux-Kernel lernt ständig neue Funktionen und wird dadurch immer fetter. Aber ist das überhaupt ein Problem? Und wofür ist der ganze Code überhaupt zuständig?

In Pocket speichern vorlesen Druckansicht 207 Kommentare lesen
Zahlen bitte! Linux: mehr als 25 Millionen Zeilen Code
Lesezeit: 8 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Das Quellcodeverzeichnis des Linux-Kernels hat jüngst die Marke von 25 Millionen Zeilen durchbrochen – Leerzeilen, Kommentare, Dokumentation, Bilder und einiges andere eingeschlossen. Ein Ende des Wachstums ist nicht in Sicht, schließlich verläuft die Linux-Entwicklung seit vielen Jahren nach demselben Muster: Linus Torvalds veröffentlicht alle neun oder zehn Wochen eine neue Kernel-Version. Damit legte Linux durch neue Funktionen und verbesserte Treiber zuletzt durchschnittlich 290.000 Zeilen zu. Kein Wunder, denn immer wieder erscheinen neue Hardware-Komponenten und Computer-Techniken, die irgendwer mit Linux einsetzen will – früher oder später sorgen Hersteller, Linux-Distributoren und gelegentlich auch Hobby-Entwickler daher für Support im Kernel.

Zahlen, bitte!

In dieser Rubrik stellen wir immer dienstags verblüffende, beeindruckende, informative und witzige Zahlen aus den Bereichen IT, Wissenschaft, Kunst, Wirtschaft, Politik und natürlich der Mathematik vor.

Reminder: Der Begriff "Linux" meint in diesem Text nur den Kernel dieses Namens und nicht damit gebaute Betriebssysteme wie Android, Fritz!OS oder Ubuntu. Bei der Sonntagnacht veröffentlichten dritten Vorabversion von Linux 4.14 umfassen die Quellen eben dieses Kernels exakt 25.023.143 Zeilen.

Eineinhalb Tage später bei der Publikation dieses Textes stimmt diese Zahl zufällig noch. Wenig später wird sie aber Geschichte sein, denn Linus Torvalds integriert nahezu jeden Tag einige Änderungen in den Hauptentwicklungszweig von Linux. Dort bereitet er gerade Linux 4.14 vor, das in der ersten Novemberhälfte erscheinen dürfte. Linux 4.13 lag mit 24.767.008 Quellcodezeilen noch knapp unter der 25-Millionen-Marke. Diese durchstieß der Kernel, als Torvalds die Wesentlichen Änderungen am Netzwerk-Subsystem für 4.14 integrierte, die andere Entwickler zuvor gesammelt und begutachtet hatten.

Linux besteht im Wesentlichen aus C- und Assembler-Code, der sich laut dem Analysewerkzeug Cloc auf zirka 16.500.000 Zeilen summiert.

Zum Vergleich: Die Dateien im Quellcodebaum von Firefox 56 enthalten 31.342.142 Zeilen, die von LibreOffice 5.4 kommen auf 17.171.162. Falls Sie jetzt "blöder Äpfel- und Birnen-Vergleich" denken, hier die Zahlen zu den Kerneln von FreeBSD 11.1 und NetBSD 7.1: 8.960.399 respektive 7.183.689 Zeilen. Auch das ist aber letztlich nur ein Äpfel- und Birnen-Vergleich, schließlich unterstützt Linux deutlich mehr Architekturen und bietet viel mehr Funktionen – zugleich beherrschen natürlich auch die beiden BSD-Derivate eine Reihe von Dingen, die Linux nicht kann.

Einen Vergleich mit dem Kernel von Windows müssen wir schuldig bleiben: Microsoft hält ihn unter Verschluss und sagt auch nicht, wie viel Zeilen sein Quellcode aktuell umfasst. Diese Zahl gegenüber zu stellen wäre aber noch abwegiger als der BSD-Vergleich, schließlich nutzt Windows einen Hybrid-Kernel. Die Kernfunktionen solcher Kernel exportieren feste Programmierschnittstellen, über den Dateisysteme, Treiber und vielen anderen Funktionen andocken können; diese können daher unabhängig vom Kern des Kernels entwickelt werden, was Microsoft vermutlich auch macht.

Linux ist hingegen ein monolithischer Kernel, bei dem Kernfunktionen, Dateisystemcode, Treiber und die sie umgebende Infrastruktur alle im einem Quellcodebaum stecken. Sie tauschen sich über Programmierschnittstellen aus, die die Linux-Entwickler immer mal wieder anpassen, um neuen Anforderungen gerecht zu werden. Da der ganze Code an einer Stelle liegt, brauchen sie sich dabei nicht um Abwärtskompatibilität scheren: Sie passen beim Ändern der Schnittstellen einfach auch den Code an, der diese verwendet. Bei den von Anwendungen verwendeten Programmierschnittstellen (die "Userspace-API") ist den Kernel-Entwicklern die Abwärtskompatibilität aber heilig.

Das die meisten Treiber enthaltene Verzeichnis enthält das Gros des Quellcodes.

Treiber stellen das Gros des Linux-Quellencodes, denn allein im Verzeichnis drivers/ stecken derzeit 14.966.279 Codezeilen. Das sind noch nicht mal alle Treiber, denn jene für Sound-Hardware liegen in sound/. Nun könnte man das Verzeichnis bei einer Analyse natürlich leicht dazurechnen – in den 1.048.676 dort liegenden Codezeilen steckt aber auch einiges an Infrastruktur, über die Anwendungen mit den Audio-Funktionen des Kernel und seinen Sound-Treibern interagieren. Wenn man diesen Code mitrechnet, müssten man fairerweise auch Verzeichnisse wie block/, crypto/ und net/ mitzählen, schließlich stellen sie die Infrastruktur zum Einsatz von Storage-, Crypto- und Netzwerk-Hardware.

Beim Architektur-Code dominiert nicht die Unterstützung für 32- und 64-Bit-x86-Prozessoren, sondern die für 32-Bit-ARM-CPUs.

Ohnehin: Was sind eigentlich Treiber? In der Windows-Welt (und manchmal auch bei Linuxern) ist oft von "Dateisystem-Treibern" die Rede, daher müsste man vielleicht auch den Dateisystemcode mitrechnen, der im Verzeichnis fs/ (1.225.434 Zeilen) liegt. Mit Hardware-Unterstützung hat der aber eigentlich gar nichts zu tun. Für die ist hingegen der in arch/ liegende Code sehr wichtig, der für die Unterstützung der verschiedenen Prozessor- und Systemarchitekturen zuständig ist – solcher Code gilt aus uns unerfindlichen Gründen aber gemeinhin nicht als Treiber. Aber wie auch immer: Das Verzeichnis mit dem architekturspezifischen Code ist mit 3.722.764 Zeilen das zweitgrößte Top-Level-Verzeichnis der Linux-Quellen. Spitzenreiter dort sind die Verzeichnisse mit Code für ARM, Powerpc/PPC und MIPS; jenes für 32- und 64-Bit-x86-Systeme folgt erst an vierter Stelle.

Die vage Definition von Treibern ist einer der Gründe, warum sich keine klare Aussage treffen lässt, wie viele Treiber in Linux stecken. Einen groben Anhaltspunkt liefern immerhin die Daten der Linux Kernel Driver DataBase (LKDDb): Treiber lassen sich typischerweise als Kernel-Modul kompilieren und die kann man zählen. Wenn man sich dabei auf Module beschränkt, die aus den Verzeichnissen drivers/ und sound/ entstehen, ergibt sich eine stattliche Zahl von zirka 7250 Treibern.

Noch weniger lässt sich die Frage beantworten, wie viele Hardware-Komponten der Kernel damit unterstützt. Indizien gibt es aber auch hier: Laut der LKDDb enthalten die Treiber von Linux rund 16.000 Identifikationsbezeichner für PCI- und USB-Hardware, durch die der Kernel weiß, für welche Hardware es welchen Treiber laden muss; nimmt man noch IDs für Geräte der Klassen ACPI, Firewire, HID, Input, Platform und Virtio dazu, steigt die Zahl sogar auf rund 21.500.

Durch Geräte-Identifikationsbezeichner weiß der Kernel, welchen Treiber es für eine bestimmte Hardware laden muss; manche Treiber sind aber für tausende verschiedener Chips zuständig.

Tatsächlich unterstützt Linux aber noch viel mehr Hardware: Manche der PCI- und USB-IDs stehen nicht für einzelne Geräte, sondern für ganze Geräteklassen, die universelle Treiber versorgen. So ist es beispielsweise beim AHCI-Treiber, der die SATA-Adapter in hunderten oder tausenden verschiedener Chips unterstützt, die AMD, Broadcom, Intel, Marvell, VIA und wie sie alle heißen in den letzten Jahren hergestellt haben oder in Zukunft bauen. Ähnlich verhält wie bei AHCI verhält es sich auch bei den Treibern für USB-Datenträger.

Zahlen zur Menge des Linux-Quellcodes triggern oft Aussagen wie "Linux wird immer fetter und muss dringend auf Diät!". Das ist ein facettenreiches Thema mit vielen diskussionswürdigen Aspekten. Der Umfang der Quellen ist aber eine eher schlechte Diskussionsgrundlage, schließlich ist der vornehmlich nur für die Programmierer relevant, die den Code pflegen und weiterentwickeln. Die aber scheren sich um den Gesamtumfang kein bisschen. Im Gegenteil: Die Entwickler des Linux-Kernels integrieren sogar Treiber für nur innerhalb von Firmen genutzte Spezial-Hardware, weil das Vorteile für alle Seiten hat.

Für die übrige Welt sind andere Dinge relevanter – beispielsweise die Angriffsfläche oder der Ressoucenverbrauch der Kernel-Images, die aus dem Quellcode entstehen. Und ja, da wird Linux tatsächlich nach und nach etwas fetter. Aber nur langsam – aber selbst darauf haben einige Kernel-Entwickler ein Auge, weil sie wollen, dass Linux auch für die Hardware des Internet-of-Things (IoT) taugt.

Letztlich sorgt die flexible Linux-Konfiguration nämlich nach wie vor dafür, dass sich der Kernel gut für die unterschiedlichsten Einsatzzwecke maßschneidern lässt. Dadurch eignet er sich nach wie vor auch für Embededed-Hardware mit 16 oder 32 Megabyte Arbeitsspeicher – aus den gleichen Quellen entstehen aber halt auch Kernel, die fabelhaft zu hunderttausend verschiedener Desktop-PCs passen oder Cluster zum High-Performance-Computing (HPC) antreiben.

Das zeigt: Treiber, Infrastruktur, Dateisysteme und vieles andere zusammen mit den Kern-Funktionen an einer Stelle zu entwickeln, hat auch seine Vorteile. Dieser Aspekt hat Linux sicherlich mit zur Dominanz verholfen, die es in vielen Bereichen dieser Tage hat – und das vielleicht nicht trotz, sondern gerade weil stabile Programmierschnittstelle für unabhängig von den Linux-Quellen entwickelte Kernel-Treiber fehlen. (thl)