Wie ist der Vergleich zwischen Linux-Kernel und Mikrokernel-Architekturen?

Ich habe einmal gelesen, dass ein Vorteil einer Mikrokernel-Architektur darin besteht, dass Sie wichtige Dienste wie Netzwerke und Dateisysteme stoppen / starten können, ohne das gesamte System neu starten zu müssen. Aber wenn man bedenkt, dass Linux-Kernel heutzutage (war es immer so?) Die Möglichkeit bietet, Module zu verwenden, um den gleichen Effekt zu erzielen, was sind die (verbleibenden) Vorteile eines Mikrokerns?

Mikrokerne erfordern weniger Code, um im innersten, vertrauenswürdigsten Modus ausgeführt zu werden als monolithische Kernel . Dies hat viele Aspekte, wie zum Beispiel:

• Mit Mikrokernen können nicht grundlegende Funktionen (z. B. Treiber für nicht angeschlossene oder nicht verwendete Hardware) nach Belieben geladen und entladen werden. Dies ist meistens unter Linux mit Hilfe von Modulen möglich.
• Mikrokerne sind robuster: Wenn eine Nicht-Kernel-Komponente abstürzt, wird nicht das gesamte System mitgenommen. Ein fehlerhaftes Dateisystem oder ein Gerätetreiber kann ein Linux-System zum Absturz bringen. Linux kann diese Probleme nur durch Codierungspraktiken und -tests lindern.
• Mikrokerne haben eine kleinere Trusted-Computing-Basis . Selbst ein böswilliger Gerätetreiber oder Dateisystem kann nicht die Kontrolle über das gesamte System übernehmen (z. B. kann ein Treiber zweifelhafter Herkunft für Ihr neuestes USB-Gadget Ihre Festplatte nicht lesen).
• Eine Konsequenz des vorherigen Punktes ist, dass normale Benutzer ihre eigenen Komponenten laden können, die Kernelkomponenten in einem monolithischen Kernel wären.

Unix-GUIs werden über das X-Fenster bereitgestellt, bei dem es sich um Userland-Code handelt (mit Ausnahme (eines Teils) des Videogerätetreibers). Viele moderne Unices ermöglichen es normalen Benutzern, Dateisystemtreiber über FUSE zu laden . Einige der Linux-Netzwerkpaketfilter können im Benutzerland durchgeführt werden. Gerätetreiber, Scheduler, Speichermanager und die meisten Netzwerkprotokolle sind jedoch weiterhin nur für den Kernel bestimmt.

Ein Klassiker (wenn datiert) über Linux und Mikrokerne ist die Tanenbaum-Torvalds-Debatte . Zwanzig Jahre später könnte man sagen, dass Linux sich sehr langsam in Richtung einer Mikrokernel-Struktur bewegt (ladbare Module erschienen früh, FUSE ist neuer), aber es ist noch ein weiter Weg.

Eine weitere Änderung betrifft die zunehmende Relevanz der Virtualisierung auf Desktop- und High-End-Embedded-Computern: In einigen Fällen wird nicht zwischen Kernel und Userland, sondern zwischen Hypervisor- und Gastbetriebssystemen unterschieden.

Ein Mikrokernel begrenzt die Zeit, die sich das System im Kernelmodus befindet, im Gegensatz zum Benutzerbereich auf das absolut mögliche Minimum.

Wenn im Kernel-Modus ein Absturz auftritt, fällt der gesamte Kernel aus, was bedeutet, dass das gesamte System ausfällt. Wenn im Benutzermodus ein Absturz auftritt, wird nur dieser Vorgang abgebrochen. Linux ist in dieser Hinsicht robust, aber es ist dennoch möglich, dass ein Kernel-Subsystem absichtlich oder versehentlich über den Speicher eines anderen Kernel-Subsystems schreibt.

Das Mikrokernel-Konzept ordnet dem Benutzer eine Menge Dinge zu, die traditionell im Kernel-Modus vorliegen, z. B. Netzwerke und Gerätetreiber. Da der Mikrokern nicht wirklich für viel verantwortlich ist, kann er auch einfacher und zuverlässiger sein. Stellen Sie sich vor, wie das IP-Protokoll, wenn es einfach und dumm ist, wirklich zu robusten Netzwerken führt, indem es die Komplexität an den Rand treibt und den Kern schlank und gemein lässt.

Sie sollten die andere Seite des Problems lesen:

Extreme High Performance Computing oder Warum Mikrokerne scheiße sind

Das Dateisystem gehört in den Kernel

Werfen Sie einen Blick auf die x86-Architektur - der monolithische Kernel verwendet nur die Ringe 0 und 3. Eigentlich eine Verschwendung. Aber dann kann es schneller sein, weil weniger Kontext wechselt.

1. Monolithischer Kernel ist viel älter als Mikrokernel . Es wird in Unix verwendet, während die Idee des Mikrokerns Ende der 1980er Jahre aufkam .

2. Beispiele für Betriebssysteme mit dem monolithischen Kernel sind UNIX, LINUX, während die Betriebssysteme mit dem Mikrokernel QNX, L4, HURD und anfänglich Mach (nicht MacOS X) sind, das später in einen Hybridkernel konvertiert wurde. Auch MINIX ist kein reiner Mikrokernel, da seine Gerätetreiber als Teil des Kernels kompiliert werden.

3. Monolithische Kerne sind schneller als Mikrokerne . Der erste Mach-Mikrokern ist 50% langsamer als monolithische Kernel. Spätere Versionen wie L4 sind nur 2% oder 4% langsamer als der monolithische Kernel .

4. Monolithische Kernel sind im Allgemeinen sperrig, während reiner Mikrokernel klein sein muss und sogar in den Cache der ersten Ebene des Prozessors (Mikrokernel der ersten Generation) passt.

5. In monolithischen Kerneln befinden sich die Gerätetreiber im Kernelbereich, während sich die Mikrokernel-Gerätetreiber im Benutzerbereich befinden .

6. Da sich die Gerätetreiber im Kernel befinden, ist der monolithische Kernel weniger sicher als der Mikrokernel (Fehler im Treiber können zum Absturz führen). Mikrokerne sind sicherer als monolithische Kerne und werden daher in vielen militärischen Geräten verwendet.

7. Monolithische Kernel verwenden Signale und Sockets , um IPC sicherzustellen, während der Mikrokernel-Ansatz Nachrichtenwarteschlangen verwendet . Die 1 ^st gen von Mikro - Kernel schlecht IPC implementiert , so dass sie auf Kontextwechsel langsam waren.

8. Wenn Sie einem monolithischen System neue Funktionen hinzufügen, müssen Sie den gesamten Kernel neu kompilieren, während Sie neue Funktionen oder Patches ohne Neukompilierung hinzufügen können

Windows NT (der Kernel, der den aktuellen Windows-Systemen zugrunde liegt) war ursprünglich ein recht vanilles Mikrokernel-Design. Aufgrund von Leistungsproblemen ist immer mehr des "Userland" -Codes in den "Micokernel" migriert.

Der Fall ist, dass der Linux-Kernel ein Hybrid aus monolithischem Kernel und Mikrokernel ist. In einer rein monolithischen Implementierung werden zur Laufzeit keine Module geladen.

Die Begriffe monolithic kernelund microkernelkönnen nicht ernsthaft verglichen werden, da sie verschiedene Aspekte des Kernel-Designs beschreiben (Struktur vs. Größe).

Ein typischer monolithischer Kernel war der SunOS-4.x-Kernel, und Linux ist immer noch ähnlich, da Sie den Inhalt des Basiskernels manuell konfigurieren.

Der Solaris-Kernel (ab 2.1 im Jahr 1992) kann nicht mehr als monolithisch bezeichnet werden, da alle Treiber bei Bedarf automatisch geladen werden und beim ersten Start nur ein winziger Teil geladen wird.

SunOS-4.x und Solaris (SunOS-5.x) sowie Linux sind alles Einzelkontextimplementierungen. Ihr gesamter Code wird in einem einzelnen MMU-Kontext ausgeführt.

Mac OS X basiert auf Mach und wird als Implementierung mit mehreren Kontexten ausgeführt, wobei mehrere Prozesse durch MMU-Kontexte getrennt sind. In diesem Konzept befinden sich die Treiber in separaten Prozessen und in separaten MMU-Kontexten.

Viele Leute nennen Mac OS X ein "Mikrokernel-System", aber es kann sein, dass der Basiskernel nicht kleiner ist als der Basiskernel von Solaris.

So scheint es , dass es zu reden wäre besser single context kernelsgegen multi context kernels.