Wikipedia

Linux (Kernel)

Unix-ähnlicher, monolithischer Betriebssystem-Kernel, Basis aller Linux-Betriebssysteme / Linux-Distributionen
Dies ist einealte Versiondieser Seite, zuletzt bearbeitet am 23. Oktober 2005 um 16:05 Uhr durchAF666(Diskussion|Beiträge)(→Weblinks).Sie kann sich erheblich von der aktuellen Version unterscheiden.
Einegesichtete Versiondieser Seite, die am15. November 2016freigegebenwurde, basiert auf dieser Version.

Linuxim eigentlichen Sinne ist „nur “einBetriebssystemkern(engl.Kernel), der in verschiedenen Betriebssystemen zum Einsatz kommt. Dieser Artikel beschreibt eben diesenLinux-Kernel.Der BegriffLinuxwird jedoch auch für mehr als nur den Betriebssystemkern verwendet, siehe dazuLinux.

Linux (Linux-Kernel)
Tux, der Linux-Pinguin
Tux,der Linux-Pinguin
Entwickler Linus Torvalds,uvm.
Lizenz(en) GPL
Erstveröff. 17. September 1991
Akt.Version Erscheinungstermine(1991–2005)
Abstammung -
Sonstiges Preis: kostenlos
Sprache:Englisch
http://kernel.org/

Linux wurde ursprünglich 1991 vom FinnenLinus Torvalds,von dem die Entwicklung auch heute noch koordiniert wird, für diex86-Architektur geschrieben. Er steht unter derfreienGPL-Lizenz. Inzwischen ist Linux auch eine auf ihn eingetragenenotorisch bekannte Marke(Warenzeichen).

Kernel-Versionen

Auf der WebsiteKernel.orgwerden alle alten und neuen Kernel-Versionen archiviert. Dieser Referenzkernel wird auch Vanilla-Kernel genannt (von umgangssprachlich engl.vanillafürStandard...). Auf diesem bauen die so genannten Distributionskernel auf, die von den einzelnenDistributorenum weitere Funktionen ergänzt werden.

Versionsnummern-Schema

Die Versionen des Linux-Kernels folgen dabei einem bestimmten Schema:

Dieerste Zifferwird 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.

Diezweite Ziffergibt das jeweilige „Majorrelease “an. Bisher wurden stabile Versionen (sog. Produktionskernel) von den Entwicklern stets durch gerade Ziffern wie 2.2, 2.4 und 2.6 gekennzeichnet, während die Testversionen (sog. Entwicklerkernel) immer ungerade Ziffern trugen, wie z. B. 2.3 und 2.5, diese Trennung ist aber seit Juli 2004 ausgesetzt, es gibt zur Zeit (2005) keinen Entwicklerkernel mit der Nummer 2.7.

Zusätzlich bezeichnet einedritte Zahldas „Minorrelease “. Beim stabilen Zweig werden hier normalerweise nur Fehlerbereinigungen und Sicherheitsupdates zugelassen. Der Kernel wird damit zum Beispiel mit einerVersionsnummerwie 2.6.7 (Produktionskernel) oder 2.5.75 (Entwicklerkernel) bestimmt.

Um die Korrektur eines schwerwiegendenNFS-Fehler schneller verbreiten zu können, wurde mit der Version 2.6.8.1 erstmals einevierte Ziffereingeführt. Seit März 2005 (Kernel 2.6.11) wird diese Nummerierung offiziell verwendet. So ist es möglich, die Stabilität des Kernels trotz 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.1auf 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 so genannten-mmKernel des KernelentwicklersAndrew Mortonund 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 istDavid Weinehallfür die 2.0er Serie verantwortlich,Marc-Christian Petersenfür den Kernel 2.2,Marcelo Tosattifür den Kernel 2.4 undAndrew Mortonfür den aktuellen stabilen Kernel 2.6. Zusätzlich zu diesen offiziellen und über Kernel.org oder einen seinerMirrorszu beziehenden Kernel-Quellcodes kann man auch alternative „Kernel-Trees “aus anderen Quellen benutzen.Distributorenvon 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 beinhalten, 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 resp. Fehlerfreiheit dennoch gewährleistet ist.

Erscheinungstermine

Datum Anmerkung Version Aktuell
17. September 1991 Initial Public Release v 0.01 -
5. Oktober 1991 v 0.02 -
13. März 1994 v 1.0.0 -
6. April 1994 v 1.1.0 -
7. März 1995 v 1.2.0 -
12. Juni 1995 v 1.3.0 -
9. Juni 1996 v 2.0.0 2.0.40
30. September 1996 v 2.1.0 -
26. Januar 1999 v 2.2.0 2.2.26
11. Mai 1999 v 2.3.0 -
4. Januar 2001 v 2.4.0 2.4.31
23. November 2001 v 2.5.0 -
18. Dezember 2003 v 2.6.0 2.6.13.4

Neuerungen im Kernel 2.6

Der aktuelle stabile Kernel wurde ab Dezember2001auf Basis des damaligen 2.4er Kernels entwickelt und weist eine Reihe von Neuerungen auf. Die wohl offensichtlichste Änderung gegenüber Version 2.4 zeigt sich, wenn man zum ersten Mal eine grafische Oberfläche auf dem neuen Kernel startet: DieX-Oberflächefühlt sich spürbar „schneller “und reaktionsfreudiger an, und andere interaktive Anwendungen wie z. B. Soundwiedergabe laufen nun auch unter hoher Last ohne Aussetzer. 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 Molnar für den 2.6er Kernel komplett neu konzipiert und implementiert hat.

Der neue O(1)-Scheduler erhielt seinen Namen, weil die relevantenAlgorithmen,auf denen der Scheduler basiert, dieKomplexitätO(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.

Nachdem alle Prozesse in der zweiten Liste stehen, werden dieArraysgetauscht, 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 man z. B. nicht ewig auf eine Reaktion der grafischen Oberfläche warten). Der neue Scheduler besitzt ausgefeilteHeuristiken,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 von 100 Hz auf 1000 Hz erhöht, d. h. die maximale Länge einer Zeitscheibe beträgt nun 1/1000 Sekunde. Auch hiervon profitieren besonders die interaktiven Prozesse, da sie früher „wieder an der Reihe sind “.

Eine weitere Stärke des neuen Schedulers liegt im verbessertenThread-Management und der besseren Unterstützung von symmetrischem Multiprocessing (SMP) undHyper-Threading.Dies kommt vor allem hoch belastetenServernzugute. In Testsituationen konnten unter dem neuen Scheduler 100.000Threadsgestartet 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 her wechseln zu lassen.

Präemptiver Kernel

Der Kernel ist ab Version 2.6 in den meisten Funktionenpräemptiv,d. h. selbst wenn das System gerade imKernel-ModusAufgaben ausführt, kann dieser Vorgang durch einen Prozess aus demUser-Modusunterbrochen werden. Der Kernel macht dann weiter, wenn der Usermodus-Prozess seinen Timeslice aufgebraucht hat. Dies funktioniert bis auf einige Kernel-Funktionen, dieatomar(nicht unterbrechbar) ablaufen müssen, sehr gut und kommt ebenfalls der Interaktivität zugute.

Inotify

Mit dem Kernel 2.6.13 hält erstmals Inotify Einzug in den Kernel. Dies ermöglicht das ständige Ü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.

Weitere wichtige Änderungen

Soweit es möglich ist, wird im Linux-Kernel 2.6 die Maximalzahl für bestimmte Ressourcen angehoben. Die Anzahl von möglichen Benutzern und Gruppen wurde von 65.000 auf über 4 Milliarden erhöht, 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 neuenNative POSIX Thread Libraryund den Netzwerk-Stack, der nun ebenfalls in den meisten Tests O(1) skaliert ist.

Grundlegende Technologie

Aufgaben des Kernels

Der Kernel bildet die hardwareabstrahierende Schicht, d. h. er stellt der auf dieserBasisaufsetzendenSoftwareeine einheitlicheSchnittstelle(API), unabhängig von derHardwarearchitektur,zur Verfügung. Er ist ein modularermonolithischer Betriebssystemkernund ist zuständig fürSpeicherverwaltung,Prozessverwaltung,Multitasking,Lastverteilung, Sicherheitserzwingung und Eingabe/Ausgabe-Operationen auf verschiedenen Geräten.

Siehe auch:Kernel

Funktionsweise

Bei einem strikt monolithischen Kernel wird der gesamte Quellcode inklusive aller Treiber in das Kernel-Image (den ausführbaren Kernel) kompiliert. Der Linux-Kernel benutzt Module, 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 dasBIOSdes Systems, u. a. auf die Erweiterungen gemäß den StandardsAPM,ACPIundVESA.Um unter diesen Voraussetzungenx86-kompatible Hardware z. B. auf derDEC-Alpha-Plattform zu betreiben, werden teilweise sogarEmulatorenzur Ausführung entsprechendenROM-Codesverwendet. Linux selbst übernimmt das System beim Bootprozess typischerweise in dem Moment, wo derBIOS-Bootloadererfolgreich war und alleSysteminitialisierungendesBIOSabgeschlossen sind.

Der Linux-Kernel ist fast komplett in der ProgrammierspracheCgeschrieben, wobei einigeGNU-C-Erweiterungen benutzt werden. Eine Ausnahme bilden die architekturabhängigen Teile des Codes (im Verzeichnisarchinnerhalb der Linux-Sourcen), wie z. B. der Beginn desBootvorganges,die inAssemblersprachegeschrieben sind.

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

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

Architektur

Linux ist heute einhybridmonolithischerKernel. Dies bedeutet, dass man den größten Teil der Treiber, die nicht während der ersten Startphase (bevor einDateisystemeingebunden ist) benötigt werden, als Module konfigurieren kann, die dann dynamisch nachgeladen oder auch während des Betriebs entladen werden können, wenn ihre Funktionalität nicht mehr benötigt wird. Die Treiber im Kernel und die Kernel-Modulelaufen imPrivilegiertenModus (x86:Ring0), haben also unbeschränkten Zugriff auf dieHardware.Einige wenige Module des Kernels laufen im eingeschränkten Benutzermodus (x86: Ring 3). Die Level 1 und 2 derx86-Architektur werden vom Linux-Kernel nicht genutzt.

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 einenFehlerso das System zum Absturz bringen kann.

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

Abstraktionsschichten unter Linux

Fast vollständige Abstraktion unter Linux

Die Tatsache, dass Linux nicht auf einemMikrokernelbasiert, war Thema eines berühmtenFlame WarszwischenLinus TorvaldsundAndrew S. Tanenbaum.Anfang der 1990er Jahre, als Linux entwickelt wurde, galten monolithische Kernels als obsolet (Linux war zu diesem Zeitpunkt noch rein monolithisch, die Möglichkeit, auch Module verwenden zu können, wurde erst später nachgerüstet). Die Diskussion und Zusammenfassungen ist im ArtikelGeschichte von Linuxnäher beschrieben.

Portierbarkeit

Obwohl Linus Torvalds eigentlich nicht beabsichtigt hatte, einen portierbaren Kernel zu schreiben, hat sich Linux dank des GNU CompilersGCCdoch in diese Richtung entwickelt. Es ist inzwischen mit eines der am häufigsten portierten Systeme (nur nochNetBSDläuft auf etwa gleich vielen Architekturen). Das Repertoire reicht dabei von eher exotischen Betriebsumgebungen wie demiPAQ-Handheld-Computer oder garDigitalkamerasbis hin zu Großrechnern wie IBMszSeries.

Obwohl die Portierung auf die S/390 ursprünglich ein vom IBM-Management nicht genehmigtes Unterfangen war (Siehe auch:Skunk Works), hatBig Bluewohl inzwischen Gefallen am Linux-System gefunden, und so soll auch die nächste IBM-SupercomputergenerationBlue Genemit einem eigenen Linux-Port ausgestattet werden, 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 jedermann eine einfache Möglichkeit bietet, auf einem freien System freie Software laufen zu lassen.

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

User Mode Linux

Ein besonderer Port ist dasUser Mode Linux(UML).Prinzipiell handelt es sich dabei um einen Port des Linux-Kernels 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 denVirtual MachinesvonJavaoder denJailsvonFreeBSDmöglich, in denen ein normaler Benutzer Root-Rechte haben kann, ohne dem tatsächlichen System schaden zu können.

µCLinux

µCLinuxist eine Linux-Variante für Computer ohneMemory Management Unit(MMU) und kommt vorwiegend aufMicrocontrollernundEmbedded Deviceszum Einsatz. Seit Linux-Version 2.6 ist µCLinux Teil des Linux-Projektes.

Entwicklungsprozess

Datei:Linus Torvalds heute.jpg
Linus Torvalds 2004

Die Entwicklung von Linux liegt durch die freieGPL-Lizenz 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 vor allen Dingen über das Internet austauschen. In vielen E-Maillisten, aber auch in Foren und im newsnet 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 beizutragen. 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 vonLinus Torvaldsund einigen speziell ausgesuchten Programmierern, die das letzte Wort über die Aufnahme von Verbesserungen und Patches haben.

Änderungen der Herkunftskontrolle

Der Entwicklungsprozess des Kernels selbst ist wie der Kernel ebenfalls immer weiter entwickelt worden. So führte der Rechtsprozess derSCO Groupum angeblich illegal übertragenen Code in Linux zur Einführung eines „Linux Developer's Certificate of Origin“,dass von Linus Torvalds undAndrew Mortonbekannt gegeben wurde (Quelle:Pressemitteilung OSDL). 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 that 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.“
(Linus Torvalds, 23. Mai 2004Quelle)

Das Versionskontrollsystem git

Die Versionskontrolle des Kernels unterliegt dem Programmgit.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 VersionskontrollsystemBitKeepernicht mehr lange für die Kernelentwicklung genutzt werden konnte.

Lizenz

Die bei GPL-Software übliche Klausel, dass statt der Version 2 derGNU General Public Licenseauch eine neuere Version verwendet werden kann, fehlt beim Linux-Kernel. Die Entscheidung, ob eine absehbare Version 3 derGNU General Public Licensefür den Linux-Kernel verwendet wird, ist damit prinzipiell nur mit Zustimmung aller Entwickler möglich.

Literatur

  • Wolfgang Mauerer:Linux Kernelarchitektur.Hanser Fachbuchverlag, November 2003,ISBN 3446225668
  • Robert Love:Linux-Kernel-Handbuch.Addison-Wesyley, Juli 2005,ISBN 3827322049
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Linux_(Kernel)&oldid=10220923“