See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Monolithischer Kernel – Wikipedia

Monolithischer Kernel

aus Wikipedia, der freien Enzyklopädie

Als monolithischen Kernel bezeichnet man einen Betriebssystemkern, in dem nicht nur Funktionen zu Speicher- und Prozessverwaltung und zur Kommunikation zwischen den Prozessen, sondern auch Treiber für die Hardwarekomponenten und möglicherweise weitere Funktionen direkt eingebaut sind.

Grafische Übersicht eines monolithischen Kernels
Grafische Übersicht eines monolithischen Kernels

Für die Treiber werden keine zusätzlichen Programme benötigt, was gegenüber einem Mikrokernel einen Geschwindigkeitsvorteil bringt. Allerdings sind solche Kernel fehleranfälliger, da der Teil, der abgestürzt ist, nicht einfach (wie es bei einem Mikrokernel theoretisch möglich wäre) neu gestartet werden kann, sondern sogar einen Absturz des gesamten Systems nach sich ziehen kann. Trotz dieses Vorteils ist die Stabilität der heute marktreifen Mikrokernel nicht besser, so dass man nicht von einer Überlegenheit sprechen kann.

Die Kernel-Entwickler von Linux haben die Schwächen des monolithischen Kernels schon früh erkannt und sind ihnen durch das Auslagern von Funktionalitäten in Kernel-Module begegnet. Durch die intensive Verwendung von Kernel-Modulen, auch für betriebssystemnahe Funktionen, ist das Nach- oder Neuladen von Systemfunktionen, auch während des Betriebs, sowie während der Entwicklungsphase möglich. Sie laufen somit wieder im Kernel-Modus, so dass es sich bei Linux trotzdem weiterhin um einen monolithischen Kernel handelt. Dies hat den Nachteil, dass die Schutzmechanismen moderner Prozessoren bei den Kernelmodulen nur bedingt greifen und ein fehlerhaftes Modul (im speziellen fehlerhaft arbeitende Treiber von Drittanbietern) das ganze System zum Absturz bringen kann.

Die Möglichkeit zur Portierung wird oft durch ein geschicktes internes Abstraktionsmodell umgesetzt, welches hardwarespezifische Funktionalitäten von den Allgemeinen trennt. So kann auch in einer monolithischen Kernelarchitektur ein Höchstmaß an Portabilität auf andere Hardwareplattformen erreicht werden.

Inhaltsverzeichnis

[Bearbeiten] Bekannte monolithische Kernel

[Bearbeiten] Systemaufruf in monolithischer Architektur

Aufrufe von Betriebssystemfunktionen aus einem Anwenderprogramm heraus benötigen eine Schnittstelle (API). Die Systemaufrufe lösen den Eintritt in den privilegierten Modus (Kernelmodus) aus. Dafür werden Software-Interrupts oder Traps genutzt. Die Anwendung hinterlegt Parameter und einen Identifizierer für die gewünschte Funktion im Hauptspeicher und erzeugt einen Trap. Der Prozessor unterbricht die Anwendung und startet die Trap-Behandlungsroutine (trap handler) des Betriebssystems. Die CPU-Kontrolle wird vom Anwendungsprogramm (engl. "user mode") an das Betriebssystem (engl. "kernel mode") übergeben. Über den Identifizierer kann nun die angeforderte Funktion gestartet werden. Die im Hauptspeicher abgelegten Argumente werden in den Kernadressbereich kopiert und auf ihre Konsistenz überprüft. Die CPU arbeitet den Aufruf ab. Nach Beendigung kopiert die aufgerufene Funktion entweder das Resultat oder den entstandenen Fehlercode in den Speicherbereich der Anwendung. Die Trap-Behandlung wird abgeschlossen, und es erfolgt ein Rücksetzen des Prozessors in den unpriviligierten Zustand. Die Kontrolle wird wieder an die Anwendung übergeben.

[Bearbeiten] Vorteile

  • Da die gesamten Betriebssystemfunktionen im Kernel-Modus ablaufen, wird der zeit- und rechenaufwändige Wechsel zwischen den Ringen des Protected Mode minimal gehalten.
  • Die Zuverlässigkeit wichtiger Funktionen des Betriebssystems (wie Speicherverwaltung) sind nicht direkt vom Verhalten der Userprogramme abhängig, und müssen nicht in diese abgebildet werden (Stichwort: Heap).
  • Es entfällt eine aufwändige Kommunikation zwischen den einzelnen Teilen des Betriebssystems. Dadurch werden Probleme, welche beim weiteren Aufteilen der Betriebssystemfunktionalitäten entstehen, vermieden.

[Bearbeiten] Nachteile

  • Das Auswechseln von Funktionalitäten muss durch eine geschickte Verwaltung (beispielsweise durch Module) erfolgen.
  • Bei Änderungen ist es notwendig den ganzen Kernel zu übersetzen ausser es gibt Möglichkeiten nur einzelne Module zu kompilieren.

[Bearbeiten] Betriebssysteme, die auf monolithischen Kernen aufsetzen


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -