Macro- Microkernel

A

Athaba

Libellenliebhaber
Ich frag mich schon seit einigen Tagen, was zum Teufel ein Hybrid aus Macro- und Microkernel sein soll.

Auf der Site hier lese ich, dass DragonflyBSD einen Hybriden aus Macro- und Microkernel ist.

Auf Wikipedia lese ich dann, dass ein Macrokernel ein Mischung aus Micro- und Monolythischen kernel ist (bzw. ein Kompromiss.

Wen der Macrokernel schon eine Mischung ist, was verstehe ich dann unter einer doppelten(?) Mischung *gg*

Leider finde ich nicht wircklich was zum Thema.
Hoffentlich kann mich jemand aufklären.. :D
 
Ich wette das wurde von diesem Lexikon falsch wiedergegeben. Ich denke in Wirklichkeit meinen die wohl, daß DragonFly einen Hybrid aus monolithischem und Mikrokernel nutzen will. Imho benutzt DFBSD aber im Moment noch einen reinen monolithischen.
 
D.h. es will einen Macrokernel machen?
Weisst du, warum die das machen wollen. Haben die das irgendwo erklärt?
Monolithische Kernel sollen doch schneler sein, da die nur mit sich selbst kommunizieren brauchen und nicht mit den einzelnen Modulen (hab ich mal wo gehört).
 
Kann man da heute überhaupt noch eine klare Trennlinie ziehen?
Ein monolitischer Kernel zeichnet sich ja dadurch aus das die Speicher/Prozessverwaltung im Kernel ist UND auch die Treiber für diverse Hardware. Aber wenn man sich mal die Palette der Module anschaut dann ist gerade bei den Treiber der HW zu sehen das es dort zig Module gibt und diese nicht zwangsläufig mit dem kernel gebaut werden müssen.
Wenn ein Teil des Kernels absemmelt beim monolithischen kernel dann Pustekuchen. Sollte also fehleranfälliger sein, dafür aber auch schneller (da bei einem micokernel wohl die kontextswitches um ein vielfaches höher liegen).

Mach ist ein Microkernel, MacOSX basier auf Mach mit grösser werdenden BSD Anteilen. Was ist das dann für ein Kernel? Micro, Macro,...?

Eine klare Trennung ist wohl kaum mehr möglich beim den Systemen heute imho
 
Ohne jetzt irgendeine anspielung für Linux und gegen BSD oder sowas machen zu wollen:
Im Linuxkernel ist es ja so, dass man ja die Einstellungen/Treiber/etc. entweder als Modul oder fix ein-/mitkompilieren konnte. Ist das mit einem Macrokernel gemeint. Ich empfand das System immer als schneller, wenn ich alles einkompiliere und kaum oder keine Module hatte.
 
@athaba
Nicht anders bei FreeBSD. Hier gibt es mittlerweile eine Menge Module:
Code: 
%ll /boot/kernel | wc -l
     384
Und das mit dem "Empfinden" ist immer so eine Sache, zu subjektiv. Das müsste dann schon wirklich gemessen werden.
Module haben einfach den Vorteil diese einfach zu laden oder zu entladen nach Lust und Laune und Verwendung. Warum unnötiges im Kernel mitschleppen was man nicht braucht.
 
Trotzdem bleibt Linux ein monolythischer Kern, da alle Kernelprozesse im gleichen Adress- und Speicherraum laufen.
 
@asg:

Tja, drum hab ich ja auch gesagt, dass ich es so empfunden hab.
Zum Thema "Sachen mitschleppen":
Ich kompilier ja nichts ein, was ich nicht brauch.
Ich brauch ganz _nur_ das was meine Hardware kann und kompilier _nur das ein.
Wenn ich mir mal neue Hardware leisten kann, kann ich ja mal schnell neukompilieren. So lange dauert das auch nicht.
Thx jedenfalls!

@chaos: Thx für die Erläuterung
 
Da wär ich mir nicht zu sicher. Stell dir vor du hast dir einen Rechner gekauft, sagen wir im Jahr 2001. Wenn du dein OS jetzt extrem an diesen Rechner anpasst, dann kannst du in arge Nöte geraten, wenn dir das Ding kaputt geht. Stell dir vor auf einmal gibts keine brauchbare neue Rechner mehr, die noch über einen IDE-Controller verfügen (könnte ja in relativ naher Zukunft passieren, wer weiß das schon..). Wenn du dann dein OS so extrem an deinen alten Rechner angepasst hast, dass du sämtliche SCSI- und S-ATA-Treiber rausgenommen hast, dann kannst du dieses OS in einem neuen Rechner nicht mehr starten. Das ist nur ein Beispiel, zeigt aber, daß solche Anpassung oftmals nicht zweckmäßig genug ist, als daß man so ein Risiko in Kauf nehmen müsste. Der Performancegewinn ist nicht groß genug, um sowas zu rechtfertigen - imho.

Gruß
 
Nunja, aber wenn sich das ändert macht das auch keinen Unterschied, denn entweder hast du die Sachen einkompiliert oder du hast in nem Microkernel die Module dazu geladen. Wenn dir die Zeit dazu bleibt die Module zu ändern bleibt sicher auch genug zeit den Kernel zu kompilieren, oder hab ich da was übersehen?
 
Athaba schrieb:
oder hab ich da was übersehen?
Zum Vergrößern anklicken....
Jo
Das Szenario besagte: Aus Performancegründen hast du alles aus dem monolithischen Kernel rausgenommen, was nicht in deinem alten Rechner benötigt wird. Der Markt ändert sich und es gibt keine Rechner mehr mit IDE-Controllern. Und _dann_ geht dir deiner kaputt - das Mainboard macht die Hufe hoch. Das OS, das du so schön angepasst hast wirst du auf den dann erhältlichen Rechnern nicht mehr starten können, weil du es zu unflexibel gemacht hast. Du wirst nicht ohne weiteres das System retten können. Und das alles wegen eines nicht messbaren, rein subjektiven Performancegewinns. ;)

Gruß
 
Bleiben wir bei dem Beispiel "Unterstüzung für IDE-Controllern". Das heißt die neuen Recher verwenden zum Beispiel SCSI.
Wenn ich das nicht habe, kann ich schwer booten. Ist logisch.
Wenn es aber dann heißt: "Ich lade mir die Module wie ich sie brauche"
Dann brauchst du das SCSI Modul zur selben Zeit wie auch das einkompilierte. Also ist es egal, ob es einkompiliert ist oder nicht. Notfalls boote ich von einer neuen Version des Systems mit der Unterstüzung des neuen Controllers (z.B. SCSI) und kompiliere mir nen neuen Kernel. Das muss ich doch auch machen, wenn ich Module verwende oder?

Oder hast du gemeint ein eigenes System bauen, dass überhaupt keine SCSI-Unterstüzung hat. Das wäre natürlich blöd... Aber wozu bräuchte man dann den Kernel überhaupt zu einem Nicht-GENERIC Kernel zu machen.
 
Ja hab ich denn in einem Wort was anderes behauptet? Ne hab ich nicht. Aber mir fällt grad auf, daß das ein blödes Beispiel is, weil wenn die neuen Boards keine IDE-Controller mehr haben, dann isses Wurst ob in deinem System noch andere Treiber als IDE drin sind - du wirst ja die Platte eh nicht einhängen können.. ^^ Was ich eigentlich vermitteln wollte: die Anpassung eines Kernels an ganz bestimmte Hardware machts im Notfall schwieriger beliebig Hardwarekomponenten auszutauschen.

Wie dem auch sei - das ist Offtopic, da es hier ja um was andres ging.

Gruß
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben