Linux-Kernel

Linux (Kernel)
Entwickler	Linus Torvalds u. v. m.
Sprache(n)	Englisch
Version	2.6.29.2 (27. April 2009)
Architekturen	IA-32, AMD64, Alpha AXP, Sun SPARC, Motorola 68000, PowerPC, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, IA-64, AXIS CRIS, Renesas M32R, Atmel AVR32, Renesas H8/300, NEC V850, Tensilica Xtensa und Blackfin
Größe	53,9 MB (2.6.29.2, Quelltext, bzip2-komprimiert)
Startmedium	Festplatte, CD-ROM, DVD-ROM, Diskette, Netzwerk, USB-Stick
Lizenz	Proprietär wegen BLOBs; in BLOB-freier Version GPL Version 2[1]
Sonstiges	Das Maskottchen Tux wurde für die Kernel-Version 2.6.29 vorübergehend durch Tuz, einen maskierten Beutelteufel, ersetzt.
Website	kernel.org

Linux (dt. [ˈliːnʊks]) ist ein Betriebssystemkern (engl. Kernel). Er wurde 1991 von dem Finnen Linus Torvalds für die x86-Architektur entwickelt und unter der freien GNU General Public License (GPL) veröffentlicht. (Die heute von Linus Torvalds herausgegebene Fassung des Kernels enthält jedoch proprietäre BLOBs und ist daher nicht mehr frei; Richard Stallman bezweifelt sogar, dass sie legal kopiert werden darf, da diese BLOBs im Widerspruch zur GPL stehen und die Rechte aus der GPL daher erlöschen.^[2] Die Free Software Foundation rät deshalb dazu, nur BLOB-freie Versionen von Linux einzusetzen, bei der diese Bestandteile entfernt wurden.)

Der Kern (Kernel) findet in einer Vielzahl von Distributionen und Betriebssystemen seine Anwendung. Der Begriff Linux bezeichnet somit gleichermaßen den Linux-Kern selbst, Linux-Distributionen wie auch Linux-basierte Systeme.

Grundlegende Technologie

Struktur des Linux-Kernels im Detail

Aufgaben des Kernels

Der Kernel eines Betriebssystems bildet die hardwareabstrahierende Schicht (Hardwareabstraktionsschicht), das heißt, er stellt der auf dieser Basis aufsetzenden Software eine einheitliche Schnittstelle (API) zur Verfügung, die unabhängig von der Rechnerarchitektur ist. Die Software kann so immer auf die Schnittstelle zugreifen und braucht die Hardware selbst, die sie nutzt, nicht genauer zu kennen. Linux ist dabei ein modularer monolithischer Betriebssystemkern und zuständig für Speicherverwaltung, Prozessverwaltung, Multitasking, Lastverteilung, Sicherheitserzwingung und Eingabe/Ausgabe-Operationen auf verschiedenen Geräten.

Siehe auch: Betriebssystemkern

Programmiersprache

Linux ist fast komplett in der Programmiersprache C geschrieben, wobei einige GNU-C-Erweiterungen benutzt werden. Eine Ausnahme bilden die architekturabhängigen Teile des Codes (im Verzeichnis arch innerhalb der Linux-Sourcen), wie zum Beispiel der Beginn des Bootvorganges, die in Assemblersprache geschrieben sind.

Funktionsweise

Bei einem strikt monolithischen Kernel wird der gesamte Quellcode inklusive aller Treiber in das Kernel-Image (den ausführbaren Kernel) kompiliert. Im Gegensatz dazu kann Linux Module benutzen, die während des Betriebs geladen und wieder entfernt werden können. Damit wird die Flexibilität erreicht, um unterschiedlichste Hardware ansprechen zu können, ohne sämtliche (auch nicht benötigte) Treiber und andere Systemteile im Speicher halten zu müssen.

Sind Teile der Hardwarespezifikationen nicht genügend offengelegt, so stützt sich Linux notfalls über spezielle VM86-Modi auch auf das BIOS des Systems, u. a. auf die Erweiterungen gemäß den Standards APM, ACPI und VESA. Um unter diesen Voraussetzungen x86-kompatible Hardware z. B. auf der DEC-Alpha-Plattform zu betreiben, werden teilweise sogar Emulatoren zur Ausführung entsprechenden ROM-Codes verwendet. Linux selbst übernimmt das System beim Bootprozess typischerweise in dem Moment, wo der BIOS-Bootloader erfolgreich war und alle Systeminitialisierungen des BIOS abgeschlossen sind.

Der Kernel ist ein Betriebssystemkern und darf nicht als das eigentliche Betriebssystem verstanden werden. Dieses setzt sich aus dem Kern und weiteren grundlegenden Bibliotheken und Programmen (die den Computer erst bedienbar machen) zusammen.

Siehe auch: Gerätenamen unter Linux, Network Block Device, Linux (Betriebssystem)

Architektur

Linux ist ein monolithischer Kernel. Die Treiber im Kernel und die Kernel-Module laufen im privilegierten Modus (x86: Ring 0), haben also unbeschränkten Zugriff auf die Hardware. Einige wenige Module des Kernels laufen im eingeschränkten Benutzermodus (x86: Ring 3). Die Level 1 und 2 der x86-Architektur werden von Linux nicht genutzt.

Nahezu jeder Treiber kann auch als Modul zur Verfügung stehen und vom System dann dynamisch nachgeladen werden. Ausgenommen davon sind Treiber, die für das Starten des Systems verantwortlich sind, bevor auf das Dateisystem zugegriffen werden kann. Man kann allerdings den Kernel so konfigurieren, dass ein Cramfs- oder Initramfs-Dateisystem vor dem tatsächlichen Root-Dateisystem geladen wird, welches die weiteren für den Startprozess notwendigen Module enthält. Dadurch kann die Kernelgröße verringert und die Flexibilität drastisch erhöht werden.

Im System laufende Programme bekommen wiederum vom Kernel Prozessorzeit zugewiesen. Jeder dieser Prozesse erhält einen eigenen, geschützten Speicherbereich und kann nur über Systemaufrufe auf die Gerätetreiber und das Betriebssystem zugreifen. Die Prozesse laufen dabei im Benutzermodus (user mode), während der Kernel im Kernel-Modus (kernel mode) arbeitet. Die Privilegien im Benutzermodus sind sehr eingeschränkt. Abstraktion und Speicherschutz sind nahezu vollkommen, ein direkter Zugriff wird nur sehr selten und unter genau kontrollierten Bedingungen gestattet. Dies hat den Vorteil, dass kein Programm z. B. durch einen Fehler das System zum Absturz bringen kann.

Linux stellt wie sein Vorbild Unix eine vollständige Abstraktion und Virtualisierung für nahezu alle Betriebsmittel bereit (z. B. virtueller Speicher, Illusion eines eigenen Prozessors etc.).

Fast vollständige Abstraktion unter Linux

Die Tatsache, dass Linux nicht auf einem Mikrokernel basiert, war Thema eines berühmten Flame Wars zwischen Linus Torvalds und Andrew S. Tanenbaum. Anfang der 1990er Jahre, als Linux entwickelt wurde, galten monolithische Kernels als obsolet (Linux war zu diesem Zeitpunkt noch rein monolithisch). Die Diskussion und Zusammenfassungen sind im Artikel Geschichte von Linux näher beschrieben.

Durch Erweiterungen wie FUSE und durch die zunehmende Verwendung von Kernel-Prozessen fließen mittlerweile auch Mikrokernel-Konzepte ein.

Portierbarkeit

Obwohl Linus Torvalds eigentlich nicht beabsichtigt hatte, einen portierbaren Kernel zu schreiben, hat sich Linux dank des GNU Compilers GCC weitreichend in diese Richtung entwickelt. Es ist inzwischen mit eines der am häufigsten portierten Systeme (nur noch NetBSD läuft auf etwa gleich vielen Architekturen). Das Repertoire reicht dabei von eher selten anzutreffenden Betriebsumgebungen wie dem iPAQ-Handheld-Computer, Digitalkameras oder Großrechnern wie IBMs System z bis hin zu normalen Home-PCs.

Obwohl die Portierung auf die S/390 ursprünglich ein vom IBM-Management nicht genehmigtes Unterfangen war (siehe auch: Skunk Works), plant IBM auch die nächste IBM-Supercomputergeneration Blue Gene mit einem eigenen Linux-Port auszustatten, sobald sie fertig ist.

Ursprünglich hatte Torvalds eine ganz andere Art von Portierbarkeit für sein System angestrebt, nämlich die Möglichkeit, freie GPL- und andere quelloffene Software leicht unter Linux kompilieren zu können. Dieses Ziel wurde bereits sehr früh erreicht und macht sicherlich einen guten Teil des Erfolges von Linux aus, da es jedem eine einfache Möglichkeit bietet, auf einem freien System freie Software laufen zu lassen.

Linux läuft gegenwärtig auf den folgenden Architekturen:

• Acorn Archimedes, A5000 und RiscPC-Serie (ARM, StrongARM, Intel XScale etc.)
• AMD64 (auch bekannt als x86–64): AMDs 64-bit Prozessoren AMD Athlon 64, AMD Opteron und Turion, sowie Intel-Prozessoren mit EM64T-Erweiterung (Xeon 4E)
• Atmel AVR32
• Axis Communications' CRIS
• Blackfin
• Compaq Alpha-Prozessor
• Hitachi H8/300
• Hewlett Packard PA-RISC
• IA-64: PCs mit 64bit Intel Itanium-Prozessor
• IBM S/390 und System z
• Intel 80386 und neuer: IBM-PCs und kompatible mit den CPUs 80386, 80486, und Pentium-Serie; AMD Athlon-Serie, AMD Duron; Cyrix-Prozessoren.
• Unterstützung für Intel-16-Bit-CPUs (8086, 8088, 80186, 80188 und 80286) wird derzeit im Rahmen des ELKS-Projektes entwickelt. ELKS steht für Embeddable Linux Kernel Subset und ist eine Kernel-Untermenge.
• MIPS: Maschinen von Silicon Graphics …
• Motorola 68020 und neuer: neuere Amigas, einige Atari und Apple Computer (siehe Linux68k)
• NEC v850e
• PowerPC: die meisten neueren Apple Computer (alle PCI-basierten Power Macintosh, der GameCube, begrenzte Unterstützung für NuBus Power Macs), Clones der Power Macs von Power Computing, UMAX und Motorola, mit einer „Power-UP“-Karte verbesserte Amigas (z. B. Blizzard oder CyberStorm), sowohl POWER als auch PowerPC-basierte IBM RS/6000-Systeme, verschiedenen eingebetteten PowerPC-Plattformen
• Sun SPARC und UltraSparc: Sun-Workstations
• Hitachi SuperH: Sega Dreamcast

User Mode Linux

Ein besonderer Port ist das User Mode Linux (UML). Prinzipiell handelt es sich dabei um einen Port von Linux auf sein eigenes Systemcall-Interface. Dies ermöglicht es, einen Linux-Kernel als normalen Prozess auf einem laufenden Linux-System zu starten. Der User-Mode-Kernel greift dann nicht selbst auf die Hardware zu, sondern reicht entsprechende Anforderungen an den echten Kernel durch. Durch diese Konstellation werden „Sandkästen“ ähnlich den Virtual Machines von Java oder den Jails von FreeBSD möglich, in denen ein normaler Benutzer Root-Rechte haben kann, ohne dem tatsächlichen System schaden zu können.

µClinux

µClinux ist eine Linux-Variante für Computer ohne Memory Management Unit (MMU) und kommt vorwiegend auf Microcontrollern und eingebetteten Systemen zum Einsatz. Seit Linux-Version 2.6 ist µClinux Teil des Linux-Projektes.

Kernel-Versionen

Auf der Website kernel.org werden alle alten und neuen Kernel-Versionen archiviert. Die dort befindlichen Referenzkernel werden auch als Vanilla-Kernel bezeichnet (von umgangssprachlich engl. vanilla für Standard bzw. ohne Extras im Vergleich zu Distributionskernels). Auf diesem bauen die sogenannten Distributionskernel auf, die von den einzelnen Linux-Distributionen um weitere Funktionen ergänzt werden.

Versionsnummern-Schema

Die Versionen von Linux folgen dabei einem bestimmten Schema:

Die erste Ziffer wird nur bei grundlegenden Änderungen in der Systemarchitektur angehoben. Während der Entwicklung des 2.5er Kernels kam wegen der relativ grundlegenden Änderungen, verglichen mit dem 2.4er Kernel, die Diskussion unter den Kernel-Programmierern auf, den nächsten Produktionskernel als 3.0 zu deklarieren. Torvalds war aber aus verschiedenen Gründen dagegen, sodass der resultierende Kernel als 2.6 bezeichnet wurde.

Die zweite Ziffer gibt das jeweilige „Majorrelease“ an. Bisher wurden stabile Versionen (sogenannte Produktionskernel) von den Entwicklern stets durch gerade Ziffern wie 2.2, 2.4 und 2.6 gekennzeichnet, während die Testversionen (sogenannte Entwicklerkernel) immer ungerade Ziffern trugen, wie zum Beispiel 2.3 und 2.5; diese Trennung ist aber seit Juli 2004 ausgesetzt, es gibt zur Zeit (2007) keinen Entwicklerkernel mit der Nummer 2.7, stattdessen werden die Änderungen laufend in die 2.6er-Serie eingearbeitet.

Zusätzlich bezeichnet eine dritte Zahl das „Minorrelease“, das die eigentliche Version kennzeichnet. Werden neue Funktionen hinzugefügt, steigt die dritte Zahl an. Der Kernel wird damit zum Beispiel mit einer Versionsnummer wie 2.6.7 bestimmt.

Um die Korrektur eines schwerwiegenden NFS-Fehlers schneller verbreiten zu können, wurde mit der Version 2.6.8.1 erstmals eine vierte Ziffer eingeführt. Seit März 2005 (Kernel 2.6.11) wird diese Nummerierung offiziell verwendet.^[3] So ist es möglich, die Stabilität des Kernels trotz teilweise sehr schneller Veröffentlichungszyklen zu gewährleisten und Korrekturen von kritischen Fehlern innerhalb weniger Stunden in den offiziellen Kernel zu übernehmen – wobei sich die vierte Ziffer erhöht (z. B. von 2.6.11.1 auf 2.6.11.2). Die Minorreleasenummer, also die dritte Ziffer, wird hingegen nur bei Einführung neuer Funktionen hochgezählt.

Entwicklerversion

Neue Funktionen finden sich im sogenannten -mm Kernel des Kernelentwicklers Andrew Morton und werden anschließend in den Hauptzweig von Torvalds übernommen. Somit werden große Unterschiede zwischen Entwicklungs- und Produktionskernel und damit verbundene Portierungsprobleme zwischen den beiden Serien vermieden. Durch dieses Verfahren gibt es auch weniger Differenzen zwischen dem offiziellen Kernel und den Distributionskernel (früher wurden Features des Entwicklungszweiges von den Distributoren häufig in ihre eigenen Kernels rückintegriert). Allerdings litt 2004/2005 die Stabilität des 2.6er Kernels unter den häufig zu schnell übernommenen Änderungen. Ende Juli 2005 wurde deshalb ein neues Entwicklungsmodell beschlossen, das nach dem Erscheinen der Version 2.6.13 erstmals zur Anwendung kommt: Neuerungen werden nur noch in den ersten zwei Wochen der Kernelentwicklung angenommen, wobei anschließend eine Qualitätssicherung bis zum endgültigen Erscheinen der neuen Version erfolgt.

Pflege der Kernel-Versionen

Während Torvalds die neuesten Entwicklungsversionen veröffentlicht, wurde die Pflege der älteren „stabilen“ Versionen an andere Programmierer abgegeben. Gegenwärtig ist David Weinehall für die 2.0er Serie verantwortlich, Marc-Christian Petersen (zuvor Alan Cox) für den Kernel 2.2, Willy Tarreau (zuvor Marcelo Tosatti) für den Kernel 2.4, Greg Kroah-Hartmann und Chris Wright für die aktuellen stabilen Kernel 2.6.x.y(-stable), Linus Torvalds für die aktuellen „normalen“ Kernel 2.6.x, und Andrew Morton für seinen experimentellen -mm-Zweig, basierend auf dem neuesten 2.6.x. Zusätzlich zu diesen offiziellen und über Kernel.org oder einen seiner Mirrors zu beziehenden Kernel-Quellcodes kann man auch alternative „Kernel-Trees“ aus anderen Quellen benutzen. Distributoren von Linux-basierten Betriebssystemen pflegen meistens ihre eigenen Versionen des Kernels und beschäftigen zu diesem Zwecke fest angestellte Kernel-Hacker, die ihre Änderungen meist auch in die offiziellen Kernels einfließen lassen.

Distributions-Kernel sind häufig intensiv gepatcht, um auch Treiber zu enthalten, die noch nicht im offiziellen Kernel enthalten sind, von denen der Distributor aber glaubt, dass seine Kundschaft sie benötigen könnte und die notwendige Stabilität respektive Fehlerfreiheit dennoch gewährleistet ist.

Erscheinungstermine

Legende:
Ältere Version; nicht mehr unterstützt
Ältere Version; noch unterstützt
Aktuelle Version
Aktuelle Vorabversion
Zukünftige Version

Version	Veröffentlichung	Bemerkungen	Dateien [v 1]	LoC [v 2]	Aktuelle Version
Ältere Version; nicht mehr unterstützt: 0.01	17. September 1991	Initial Public Release	90	8.413	-
Ältere Version; nicht mehr unterstützt: 0.02	5. Oktober 1991		–	-	-
Ältere Version; nicht mehr unterstützt: 1.0.0	13. März 1994		563	170.581	-
Ältere Version; nicht mehr unterstützt: 1.1.0	6. April 1994	Entwicklungsversion	561	170.320	-
Ältere Version; nicht mehr unterstützt: 1.2.0	7. März 1995		909	294.623	-
Ältere Version; nicht mehr unterstützt: 1.3.0	12. Juni 1995	Entwicklungsversion	992	323.581	-
Ältere Version; noch unterstützt: 2.0.0	9. Juni 1996		2.015	716.119	2.0.40
Ältere Version; nicht mehr unterstützt: 2.1.0	30. September 1996	Entwicklungsversion	1.727	735.736	-
Ältere Version; noch unterstützt: 2.2.0	26. Januar 1999		4.599	1.676.182	2.2.26
Ältere Version; nicht mehr unterstützt: 2.3.0	11. Mai 1999	Entwicklungsversion	4.721	1.763.358	-
Ältere Version; noch unterstützt: 2.4.0	4. Januar 2001		8.187	3.158.560	2.4.37.1
Ältere Version; nicht mehr unterstützt: 2.5.0	23. November 2001	Entwicklungsversion	9.893	3.833.603	-
Aktuelle Version: 2.6.0	18. Dezember 2003		15.007	5.475.685	2.6.29.2

1. ↑ Dateien gezählt mit „find . -type f | wc -l“
2. ↑ Lines of Code (englisch für: Quellcodezeilen); gezählt mit „find . -name *.[hcS] | xargs cat | wc -l“

Wachstum des Kernels

Neuerungen im Kernel 2.6

Die Kernel-Reihe 2.6 wurde ab Dezember 2001 auf Basis des damaligen 2.4er Kernels entwickelt und wies umfangreiche Neuerungen auf. Für die Entwicklung war der neue Kernel-Code übersichtlicher und leichter zu pflegen, während Anwender durch die Überarbeitung der Scheduler und des I/O-Bereichs und von geringeren Latenzzeiten profitierten ^[4]. Dies wurde durch eine Reihe von Maßnahmen erreicht, die im Folgenden besprochen werden sollen:

Der O(1)-Scheduler

In einem Multitasking-fähigen Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt und sie nach Ablauf der zugeteilten Zeitspanne (Timeslice) wieder „schlafen legt“. Diese Instanz bildet der sog. Scheduler, den Ingo Molnár für den 2.6er Kernel komplett neu konzipiert und implementiert hat.

Der O(1)-Scheduler erhielt seinen Namen, weil die relevanten Algorithmen, auf denen der Scheduler basiert, die Komplexität O(1) haben. Dies bedeutet, dass die vom Scheduler für eigene Aufgaben benötigte Prozessorzeit unabhängig von der Anzahl der verwalteten Prozesse bzw. Threads ist. Insbesondere wird etwa auf Durchsuchen aller Prozesse nach dem „besten“ etc. verzichtet.

Der O(1)-Scheduler arbeitet daher auch bei sehr vielen Prozessen überaus effizient und benötigt selbst sehr wenig Rechenzeit. Er verwendet prinzipiell zwei verkettete Listen, in denen die Prozesse eingetragen sind, die noch laufen wollen, und diejenigen, die bereits gelaufen sind. Wenn alle Prozesse in der zweiten Liste stehen, werden die Arrays getauscht, und das Spiel beginnt von neuem. Der Scheduler ist darüber hinaus so ausgelegt, dass Prozesse, die große Mengen Rechenzeit in Anspruch nehmen wollen, gegenüber interaktiven Prozessen benachteiligt werden, wenn beide zur gleichen Zeit laufen wollen.

Interaktive Prozesse benötigen in der Regel nur sehr wenig Rechenzeit, sind dafür aber sehr zeitkritisch (so will der Benutzer beispielsweise nicht lange auf eine Reaktion der grafischen Oberfläche warten). Der Scheduler besitzt ausgefeilte Heuristiken, um festzustellen, ob ein Prozess interaktiv ist oder die CPU eher lange belegt.

Gegenwärtig arbeiten mehrere Kernelprogrammierer noch daran, gewisse Grenzfälle auszubalancieren (ein Prozess wird plötzlich von einem interaktiven zu einem CPU-lastigen und umgekehrt). Der interne „Takt“ des Kernels wurde ab dem Kernel 2.6 von 100 Hz auf 1000 Hz erhöht, das heißt, die kürzestmögliche Länge einer Zeitscheibe beträgt nun eine Millisekunde. Auch hiervon profitieren besonders die interaktiven Prozesse, da sie früher „wieder an der Reihe sind“. Da dies aber zu einer erhöhten CPU-Last und somit zu einem größeren Stromverbrauch führt, entschied man sich, den Takt ab dem Kernel 2.6.13 auf 250 Hz voreinzustellen. Bei der Konfiguration des Kernels sind jedoch auch noch die Werte 100 Hz, 300 Hz und 1000 Hz wählbar.

Eine weitere Stärke dieses Schedulers liegt im verbesserten Thread-Management und der besseren Unterstützung von symmetrischem Multiprocessing (SMP) und Hyper-Threading. Dies kommt vor allem hoch belasteten Servern zugute. In Testsituationen konnten unter diesem Scheduler 100.000 Threads gestartet werden, ohne dass das System subjektiv langsamer wurde. Weiterhin sorgt der neue Scheduler dafür, dass die zur Verfügung stehenden CPUs optimal ausgelastet werden, ohne Prozesse übermäßig oft zwischen zwei CPUs hin- und herwechseln zu lassen.

Mit der Kernelversion 2.6.23 wurde im Oktober 2007 der O(1)-Scheduler durch einen sog. Completely Fair Scheduler ersetzt, der ebenfalls von Ingo Molnár entwickelt wurde.

Präemptiver Kernel

Der Kernel ist ab Version 2.6 in den meisten Funktionen präemptiv, d. h., selbst wenn das System gerade im Kernel-Modus Aufgaben ausführt, kann dieser Vorgang durch einen Prozess aus dem User-Modus unterbrochen werden. Der Kernel macht dann weiter, wenn der Usermodus-Prozess seine Timeslice aufgebraucht hat oder selbst einen Re-Schedule anfordert, also dem Scheduler mitteilt, dass er einen anderen Task ausführen kann. Dies funktioniert, bis auf einige Kernel-Funktionen, die atomar (nicht unterbrechbar) ablaufen müssen, sehr gut und kommt ebenfalls der Interaktivität zugute.

Zugriffskontrolllisten

Mit dem Kernel 2.6 werden für Linux erstmals Zugriffskontrolllisten (access control lists) nativ eingeführt. Diese sehr feinkörnige Rechteverwaltung ermöglicht es vor allem Systemadministratoren, die Rechte auf einem Dateisystem unabhängig vom Gruppen- und Nutzermodell zu gestalten und dabei faktisch beliebig viele spezielle Rechte pro Datei zu setzen. Die mangelnde Unterstützung von Zugriffskontrolllisten von Linux wurde vorher als massive Schwäche des Systems im Rahmen der Rechteverwaltung und der Möglichkeiten zur sicheren Konfiguration gesehen.

Die Unterstützung von Zugriffskontrolllisten funktioniert dabei mit den Dateisystemen ext2, ext3, jfs und XFS nativ.

Inotify

Mit dem Kernel 2.6.13 hält erstmals Inotify Einzug in den Kernel. Dies ermöglicht das permanente Überwachen von Dateien und Ordnern: Wird eines der überwachten Objekte geändert oder ein neues Objekt im Überwachungsraum erschaffen, gibt Inotify eine Meldung aus, die wiederum andere Programme zu definierten Tätigkeiten veranlassen kann. Dies ist insbesondere für Such- und Indexierungsmechanismen der Datenbestände von entscheidender Bedeutung, und ermöglicht erst den sinnvollen Einsatz von Desktop-Suchmaschinen wie Strigi oder Beagle. Ohne eine solche Benachrichtigungsfunktion des Kernels müsste ein Prozess die zu überwachende Datei bzw. den zu überwachenden Ordner in bestimmten Zeitintervallen auf Änderungen überprüfen, was im Gegensatz zu Inotify zusätzliche Performance-Einbußen mit sich brächte.

Weitere wichtige Änderungen

Soweit es möglich ist, wurde in Linux 2.6 die Maximalzahl für bestimmte Ressourcen angehoben. Die Anzahl von möglichen Benutzern und Gruppen erhöhte sich von 65.000 auf über 4 Milliarden, ebenso wie die Anzahl der Prozess-IDs (von 32.000 auf 1 Milliarde) und die Anzahl der Geräte (Major/Minor-Nummern). Weitere leistungssteigernde Maßnahmen betrafen die I/O-Scheduler, das Threading mit der neuen Native POSIX Thread Library und den Netzwerk-Stack, der nun ebenfalls in den meisten Tests O(1) skaliert ist. Außerdem wurde für die Verwaltung der I/O-Gerätedateien das früher genutzte devfs durch das neuere udev ersetzt, was viele Unzulänglichkeiten, wie zum Beispiel ein zu großes /dev/-Verzeichnis, beseitigt. Außerdem kann so eine einheitliche und konsistente Gerätebenennung erfolgen, die beständig bleibt, was vorher nicht der Fall war.

Zukünftige Entwicklungen

Einheitliches WLAN-Subsystem

Jeff Garzik stellte Anfang 2006 fest, dass die Situation rund um WLAN-Treiber in Linux unausgegoren war: Die meisten Treiber bauten auf verschiedenen, nicht einheitlichen Systemen auf ^[5]. Neue Treiber konnten damit nur schwer entwickelt werden, da schon zu Beginn unklar war, für welches Subsystem sie entwickelt werden sollten. Auch war das Warten verschiedener Subsysteme und alter Treiber schwierig und erforderte einen großen Zeitaufwand. Um diesen Problemen zu begegnen, wurde ein Verwalter für das WLAN-Subsystem bestimmt, John W. Linville, der sich seitdem um die Entwicklung kümmert. Seitdem wird an einem einheitlichen Subsystem auf der Basis des Advanced Datapath Drivers gearbeitet, der von der Firma Devicescape für den Kernel 2.6 freigegeben wurde ^[6].

Entwicklungsprozess

Linus Torvalds 2004

Die Entwicklung von Linux liegt durch die GNU General Public License und durch ein sehr offenes Entwicklungsmodell nicht in der Hand von Einzelpersonen, Konzernen oder Ländern, sondern in der Hand einer weltweiten Gemeinschaft vieler Programmierer, die sich hauptsächlich über das Internet austauschen. In vielen Mailinglisten, aber auch in Foren und im Usenet besteht für jedermann die Möglichkeit, die Diskussionen über den Kernel zu verfolgen, sich daran zu beteiligen und auch aktive Beiträge zur Entwicklung zu leisten. Durch diese unkomplizierte Vorgehensweise ist eine schnelle und stetige Entwicklung gewährleistet, die auch die Möglichkeit mit sich bringt, dass jeder dem Kernel Fähigkeiten zukommen lassen kann, die er benötigt.

Eingegrenzt wird dies nur durch die Kontrolle von Linus Torvalds und einigen besonders verdienten Programmierern, die das letzte Wort über die Aufnahme von Verbesserungen und Patches in die offizielle Version haben. Manche Linux-Distributoren bauen auch eigene Funktionen in den Kernel ein, die im offiziellen Kernel (noch) nicht vorhanden sind.

Änderungen der Herkunftskontrolle

Der Entwicklungsprozess des Kernels selbst ist wie der Kernel ebenfalls immer weiterentwickelt worden. So führte der Rechtsprozess der SCO Group um angeblich illegal übertragenen Code in Linux zur Einführung eines „Linux Developer's Certificate of Origin“, das von Linus Torvalds und Andrew Morton bekanntgegeben wurde.^[7] Diese Änderung griff das Problem auf, dass nach dem bis dahin gültigen Modell des Linux-Entwicklungsprozesses die Herkunft einer Erweiterung oder Verbesserung des Kernels nicht nachvollzogen werden konnte.

“These days, most of the patches in the kernel don't actually get sent directly to me. That not just wouldn't scale, but the fact is, there's a lot of subsystems I have no clue about, and thus no way of judging how good the patch is. So I end up seeing mostly the maintainers of the subsystem, and when a bug happens, what I want to see is the maintainer name, not a random developer who I don't even know if he is active any more. So at least for me, the _chain_ is actually mostly more important than the actual originator. There is also another issue, namely the fact than when I (or anybody else, for that matter) get an emailed patch, the only thing I can see directly is the sender information, and that's the part I trust. When Andrew sends me a patch, I trust it because it comes from him - even if the original author may be somebody I don't know. So the _path_ the patch came in through actually documents that chain of trust - we all tend to know the "next hop", but we do _not_ necessarily have direct knowledge of the full chain. So what I'm suggesting is that we start "signing off" on patches, to show the path it has come through, and to document that chain of trust. It also allows middle parties to edit the patch without somehow "losing" their names - quite often the patch that reaches the final kernel is not exactly the same as the original one, as it has gone through a few layers of people.”

„Zur Zeit werden die meisten Patches für den Kernel nicht direkt an mich gesandt. Das wäre einfach nicht machbar. Tatsache ist, dass es eine Menge Untersysteme gibt, mit denen ich überhaupt nicht vertraut bin, und somit keine Möglichkeit habe, zu entscheiden, wie gut der Patch ist. Deshalb läuft es meist darauf hinaus, die Pfleger(Maintainer) des Untersystemes zu treffen. Was ich sehen will, falls ein Fehler auftritt, ist der Name eines Pflegers (Maintainers) und nicht irgendeinen Entwickler von dem ich nicht einmal weiß, ob er noch aktiv ist. Daher ist wenigstens für mich die [Eingangs-]_Kette_ wichtiger als der tatsächliche Urheber. Auch gibt es ein anderes Problem, nämlich dass ich falls man mir (oder irgendjemand anderem) einen Patch über E-Mail schickt, einzig die Senderinformation direkt sehen kann, und das ist der Teil dem ich traue. Wenn Andrew mir einen Patch schickt, vertraue ich dem Patch, weil er von Andrew kommt - auch wenn der eigentliche Urheber jemand ist den ich nicht kenne. Also belegt tatsächlich der _Weg_ den der Patch zu mir nahm diese Kette des Vertrauens - wir alle neigen dazu das jeweils nächste Glied zu kennen, aber nicht unbedingt unmittelbares Wissen über die gesamte Kette zu haben. Was ich also vorschlage ist dass wir anfangen, Patches abzuzeichnen, um den Weg, den sie genommen haben aufzuzeigen und diese Kette des Vertrauens zu dokumentieren. Das erlaubt uns darüber hinaus vermittelnden Gruppen, den Patch zu verändern ohne dass dabei der Name von jemanden "auf der Strecke bleibt" - ziemlich oft ist die Patchversion, die letztendlich in den Kernel aufgenommen wird nicht genau die ursprüngliche, ist sie doch durch einige Entwicklerschichten gegangen.“

– Linus Torvalds: Linux-Kernel Archive^[8], 23. Mai 2004

Das Versionskontrollsystem Git

Die Versionskontrolle des Kernels unterliegt dem Programm Git. Dies wurde speziell für den Kernel entwickelt und auf dessen Bedürfnisse hin optimiert. Es wurde im April 2005 eingeführt, nachdem sich abgezeichnet hatte, dass das alte Versionskontrollsystem BitKeeper nicht mehr lange für die Kernelentwicklung genutzt werden konnte.

Lizenz

Die bei GPL-Software übliche Klausel, dass statt der Version 2 der GPL auch eine neuere Version verwendet werden kann, fehlt beim Linux-Kernel.^[9] Die Entscheidung, ob die im Juni 2007 erschienene Version 3 der Lizenz für Linux verwendet wird, ist damit prinzipiell nur mit Zustimmung aller Entwickler möglich. In einer Umfrage haben sich Torvalds und die meisten anderen Entwickler für die Beibehaltung der Version 2 der Lizenz ausgesprochen.

Literatur

• Wolfgang Mauerer: Linux Kernelarchitektur. Hanser Fachbuchverlag, November 2003, ISBN 3-446-22566-8
• Robert Love: Linux-Kernel-Handbuch. Addison-Wesley, Juli 2005, ISBN 3-8273-2204-9

Weblinks

• kernel.org – Das Linux-Kernel-Archiv (englisch)
• kerneltrap.org – Informationen über aktuelle Entwicklungen im Kernel (englisch)
• kernelnewbies.org – Infos für angehende Kernel-Programmierer (englisch)
• kernelplanet.org – Der offizielle Kernel-Entwicklerblog (englisch)
• Anatomy of the Linux kernel
• oldlinux.org - eine Sammlung Historischer Kernel
• Linux 0.01 - Weiterentwicklungen des 0.01 kernels für neuere GCC Versionen

Quellen

1. ↑ http://directory.fsf.org/project/linux/
2. ↑ http://www.gnu.org/philosophy/linux-gnu-freedom.html
3. ↑ Thorsten Leemhuis: Neue Kernel-Serie mit Linux 2.6.11.1 gestartet auf heise.de, 7. März 2005
4. ↑ Dr. Oliver Diedrich: The Next Generation - Linux 2.6: Fit für die Zukunft in der c't 24/2003, Seite 194
5. ↑ Jeff Garzik: State of the Union - Wireless auf der Linux-Kernel E-Mailliste. 5. Januar 2006
6. ↑ Pressemitteilung Devicescape: Devicescape releases WI-FI technology to Open Source community, 1. Mai 2006
7. ↑ Pressemitteilung OSDL: Developer's Certificate of Origin, 2004
8. ↑ Linux-Kernel Archive: [RFD] Explicitly documenting patch submission, 23. Mai 2004
9. ↑ Linus Torvalds: GPL V3 and Linux - Dead Copyright Holders. 25. Januar 2006. Abgerufen am 24. März 2009. (Nachricht auf der Linux-Kernel-Mailingliste)