Kernel-Log: 15.000.000 Zeilen Code, 3.0 wird Longterm-Kernel
Mit den ersten für Linux 3.3 aufgenommenen Änderungen haben die Kernel-Quellen die Marke von 15 Millionen Codezeilen durchbrochen. Die Pflege für Linux 2.6.32 endet vermutlich in einem Monat; Linux 3.0 und der darauf basierende Echtzeit-Kernel sollen für zwei Jahre gepflegt werden.
- Thorsten Leemhuis
Nachdem das vergangene Woche freigegebene Linux 3.2 ganz knapp unter der Marke von 15 Millionen Zeilen Quellcode blieb, hat der Kernel diese Marke am Wochenende überschritten, als Torvalds die ersten Änderungen für Linux 3.3 in den Hauptentwicklungszweig aufnahm. Damit sind die Quellen des Linux-Kernels in etwas über drei Jahren um mehr als fünfzig Prozent gewachsen, denn die 10-Millionen-Marke hat der Kernel im Oktober 2008 durchbrochen; Kommentare, Leerzeilen, Dokumentation, Skripte und Userland-Werkzeuge, die dem Kernel beiliegen, werden dabei mitgezählt (find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l ).
Unter den Kernel-Entwicklern wird der steigende Umfang eher selten kritisiert. Erst kürzlich hat Linux-Urgestein Theodore 'tytso' Ts'o auf der Mailingliste der Kernel-Entwickler angedeutet, Analysen zum Umfang hätten Unterhaltungswert, ließen aber keine Rückschlüsse auf die Komplexität zu. Letztere war in letzter Zeit häufiger Thema unter den Kernel-Entwicklern. Andrew Morton sagte etwa kürzlich bei der Begutachtung von Änderungen, die Kernel-Entwicklung hätte den Punkt überschritten, ab dem jede weitere Komplexität als Rückschritt ("regression") angesehen werden müsse. Normalerweise versuchen die Kernel-Entwickler, "Regressions" zu vermeiden, damit ein neuer Kernel keine Probleme bereitet, die die Vorgänger nicht zeigten.
Torvalds selbst hat die wachsende Komplexität vor einigen Wochen in einem Interview der "Zeit Online" ebenfalls kritisiert: Er sähe mit Bangen dem Tag entgegen, an dem die Kernel-Entwickler mit einen Fehler zu tun hätten, den niemand mehr nachvollziehen könne. Einem LWN.net-Bericht zufolge war Komplexität auch auf dem diesjährigen Treffen der Kernel-Entwickler ein Thema. Kritik gab es insbesondere am Code für das Memory Management: Demnach habe etwa die Lösung eines Problems im Umfeld von "page migration" drei wichtige Entwickler erfordert; niemand habe den Überblick über das große Ganze dieses Kernel-Bereichs. Schon im letzten Jahr hatte LWN.net einen Bericht veröffentlicht, der die Hintergründe eines während der Entwicklung von Linux 2.6.34 bemerkten Fehlers beim Code des Memory-Management-Codes erläuterte, dessen Ursache Torvalds und einige andere erfahrene Kernel-Entwickler tagelang nachgespürt hatten.
Analyse
Zum Erscheinen dieses Kernel-Log enthielt ein aktueller Git-Checkout des Hauptentwicklungszweigs von Linux 15.046.951 Zeilen. Es ist möglich, aber eher unwahrscheinlich, dass der Codeumfang wieder unter diese Marke sinkt. Langfristig ist Wachstum sicher, denn von einigen Ausreißern abgesehen waren die letzten Versionen typischerweise um hundert- bis dreihunderttausend Zeilen größer als ihre jeweiligen Vorgänger.
Eine etwas näherer Blick auf den Kernel-Code gelingt mit dem Analyse-Programm Sloccount. Bei Linux 3.2, das mit 14.998.651 Zeilen Code knapp unter der 15-Millionen-Marke liegt, sind knapp 1,9 Millionen Zeilen für die Unterstützung der verschiedenen Prozessor-Architekturen zuständig; fast 700.000 Zeilen enthält das Verzeichnis für Dateisysteme. Das Treiber-Verzeichnis ist mit 5,6 Millionen Zeilen das größte. Letztlich geht allerdings noch mehr Code auf das Konto von Treibern, denn manche finden sich in anderen Verzeichnissen – die Treiber für Sound-Hardware beispielsweise in sound/drivers/.
SLOC Directory SLOC-by-Language (Sorted)
5615064 drivers ansic=5610304,yacc=1688,asm=1475,perl=792,lex=779,sh=26
1876166 arch ansic=1632759,asm=241881,sh=692,awk=470,pascal=231, perl=58,python=45,sed=30
698974 fs ansic=698974
533134 sound ansic=532951,asm=183
493711 net ansic=493615,awk=96
301646 include ansic=299895,cpp=1709,asm=42
120454 kernel ansic=120149,perl=305
56177 tools ansic=51029,perl=3272,python=1399,sh=476,asm=1
54529 mm ansic=54529
44171 security ansic=44171
42627 crypto ansic=42627
37307 scripts ansic=22487,perl=8287,sh=2028,cpp=1820,yacc=1291,lex=947,python=447
28486 lib ansic=28473,awk=13
14382 block ansic=14382
11579 Documentation ansic=6896,perl=2369,sh=1018,python=949,lisp=218,awk=129
5705 ipc ansic=5705
4661 virt ansic=4661
2377 init ansic=2377
1876 firmware asm=1660,ansic=216
1232 samples ansic=1232
564 usr ansic=550,asm=14
0 top_dir (none)
Sloccount schaut sich die Dateien zudem noch näher an und erstellt eine Aufstellung zu den verwendeten Programmiersprachen. Demnach enthält Linux 3.2 nicht ganz 10 Millionen Zeilen Programmcode; davon sind 97 Prozent Ansi-C und 2,5 Prozent Assembler.
Totals grouped by language (dominant language first):
ansic: 9667982 (97.22%)
asm: 245256 (2.47%)
perl: 15083 (0.15%)
sh: 4240 (0.04%)
cpp: 3529 (0.04%)
yacc: 2979 (0.03%)
python: 2840 (0.03%)
lex: 1726 (0.02%)
awk: 708 (0.01%)
pascal: 231 (0.00%)
lisp: 218 (0.00%)
sed: 30 (0.00%)
Total Physical Source Lines of Code (SLOC) = 9,944,822
Das Programm wurde aber schon einige Jahre nicht mehr aktualisiert und lässt sich in die Irre leiten, wie die Angaben zum Pascal-Code zeigen. Perl- und Python-Code findet sich aber durchaus in den Linux-Quellen; bei einigen Kernel-Versionen wird der Perl-Interpreter sogar zum Übersetzen benötigt.
Linux 3.0 wird Longterm-Kernel, Staccato
Kernel-Versionsstatus
Greg Kroah-Hartman hat zum Jahresanfang die Kernel-Versionen 2.6.32.52, 3.0.15 und 3.1.7 freigegeben, die ein Problem beim Aufwachen aus systemweiten Schlafzuständen beseitigen sollen. Einige Tage später folgten der Longterm-Kernel 2.6.32.53 sowie die Stable-Kernel 3.0.16 und 3.1.8.
In einem Blog-Eintrag und einer Mail an die LKML erläuterte Kroah-Hartman wenig später, wie er bei der Pflege der verschiedenen Kernel-Versionen weiter vorgehen will. Die Betreuung der 3.1er-Reihe will er in Kürze einstellen; lediglich ein oder maximal zwei Updates sollen noch erscheinen. Linux 3.2 wird wie bei Stable-Kerneln üblich bis kurz nach der Freigabe von Linux 3.3 weiter gepflegt.
Dem bislang als "Stable-Kernel" gewarteten Linux 3.0 verlieh Kroah-Hartman den Status "Longterm-Kernel". Um den will er sich mindestens zwei Jahre kümmern, wie er es vor einigen Monaten in einer Diskussion um die Vorgehensweise bei Stable- und Longterm-Kerneln vorgeschlagen hatte.
Die Pflege des Longterm-Kernels 2.6.32 will Kroah-Hartman bald einstellen; vermutlich in einem Monat "oder so". Möglicherweise würde jemand anders die Betreuung dann übernehmen, was aber noch nicht sicher sei. Er betont in dem Rahmen, dass alle anderen Longterm-Kernel von anderen Leuten gewartet werden und er zu den weiteren Planungen dieser Entwickler nichts sagen könne.
Steven Rostedt erläuterte in Umfeld der Ankündigungen von Kroh-Hartman, die auf Echtzeit-Eigenschaften hin optimierten RT-Kernel auf Basis von Linux 3.0 (3.0.y-rtx) ebenfalls zwei Jahre warten zu wollen.
Kernel-Log-Staccato
Kernel
- Der Entwickler "argp" hat einen längeren Blog-Eintrag verfasst, der die Arbeitsweisen der drei im Kernel enthaltenen Memory Allocator SLAB, SLUB und SLOB näher erläutert. Mit einem von ihnen verwalten und verteilen moderne Kernel kleinere Häppchen des Arbeitsspeichers, daher sind sie für die System-Performance wichtig.
Unterstützung für Grafikhardware
- AMD-Entwickler Alex Deucher hat einige der Tabellen im Xorg-Wiki überarbeitet, mit denen sich unter anderem Grafikchip- und Produktnamen von AMD-Grafikhardware aufschlüsseln lassen. Mit diesen Angaben lässt sich etwa herausfinden, welche Radeon-HD-Modelle der 7000er-Reihe auf Grafikkernen der Northern-Islands-Generation basieren, für die es schon länger quelloffene Linux-Treiber gibt; die anderen Grafikkarten der im Dezember eingeführten 7000er-Serie erfordern bislang den proprietären Hersteller-Treiber. AMDs Entwickler arbeiten dem Berichten zufolge an quelloffenen Linux-Treibern, die wohl in den nächsten Woche oder Monaten freigegeben werden sollen.
- Bereits kurz vor dem Jahreswechsel hat Keith Packard die erste als "Release Candidate" eingestufte Vorabversion des für März geplanten X-Servers 1.12 veröffentlicht. Mit ihr erhielt der X-Server von X.org die im letzten Kernel-Log angesprochene Unterstützung für Multitouch. Peter Hutterer, treibende Kraft hinter der Multitouch-Implementation für den X-Server, erläutert einige Aspekte zu "Multitouch in X" in den Blog-Einträgen "Getting events", "Pointer emulation" und "Touch grab handling".
- Die nächste Version der OpenGL-Implementierung und 3D-Treiber-Sammlung Mesa 3D, die derzeit vorbereitet wird, wird die Versionsnummer 8.0 tragen. Zu diesem kürzlich vorgenommenen Versionssprung haben sich die Entwickler entschlossen, weil die für Februar geplante Version die erste sein wird, die OpenGL 3.0 vollständig unterstützt.
- Daniel Vetter hat die Version der 1.1 der intel-gpu-tools veröffentlicht, die einige vornehmlich auf Intel-Grafikhardware abgestimmte Test- und Fehlerfindungs-Werkzeuge enthalten.
- In einem Blog-Eintrag erläutert Kernel- und X.org-Entwickler Dave Airlie einige Fortschritte beim "hotplug server", durch den ein bereits laufender X-Server Grafikhardware ohne Neustart zuschalten kann. Das ist etwa für via USB angeschlossene Monitore sowie Systeme interessant, bei der man zwischen Prozessor-Grafik und separatem Grafikchip umschalten kann.
Kernel-Umland ("Plumbing layer"), Userland-Treiber, Entwicklertools, ...
- Lucas De Marchi und Gustavo Barbieri haben die Version 3 von Kmod freigegeben (1, 2). Mit ihr enthält die Software auch einen Ersatz für Depmod und somit alles Nötige, um die Module-Init-Tools zu ersetzen, zu denen auch Lsmod oder Modprobe gehören. Diese Ablösung ist mittlerweile fest geplant, wie die Entwickler (1, 2) und der Betreuer der Module-Init-Tools bekannt gaben.
- Stephen Hemminger hat die auf Linux 3.2 abgestimmte, aber auch mit älteren Kernel-Versionen arbeitende Version 3.2 von Iproute2 mit dem Werkzeug "ip" zur Netzwerkkonfiguration freigegeben.
- Mathieu Desnoyers hat das 2.0 prerelease bundle 20111223 der maßgeblich von ihm vorangetriebenen Tracing-Lösung LTTng freigegeben.
- Die kürzlich veröffentlichte Version 3.2.3 des Software-RAID-Werkzeugs Mdadm bringt bessere Unterstützung zum Reshape bei HostRAID-Controllern von Intel – also dem Vergrößern existierender RAIDs oder dem Migrieren zu einem anderen RAID-Level unter Datenerhalt.
- Karsten Keil hat Git-Depots mit Software veröffentlicht, mit der sich CAPI-2.0-Unterstützung bei passiven ISDN-Chips mit dem mISDN-Treiber nutzen lässt. Dadurch kann man beispielsweise mit passiven ISDN-Karten faxen, was der Entwickler erfolgreich testen konnte.
LKML-Diskussionen
- Tim Bird, eine der treibenden Kräfte hinter dem Android Mainlining Project, hat den Android Logger zur Begutachtung an die LKML geschickt. Damit wollte er eine Aufnahme des Frameworks vorbereiten, das Android zum Loggen nutzt. Es folgte reichlich Kritik an dem lediglich 700 Zeilen umfassenden Patch und dessen Ansatz. Bird hat die Diskussion kürzlich nochmals angeschoben und fragt kritisch, ob es trotz aller Kritik an der Implementierung nicht doch eine gute Idee sei, den Code aufzunehmen.
- Linus Torvalds hat abermals betont, neue Kernel-Funktionen sollten so gut wie nie eine Konfigurations-Vorgabe setzen, durch die diese Funktion standardmäßig eingeschaltet würde. Bereits einige Wochen zuvor hatte er einige Kernel-Entwickler mal wieder daran erinnert, dass Regressionen ("regressions") bei der Kernel-Entwicklung absolut unakzeptabel sind.
Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open und in c't. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl).
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
(thl)