Autor Thema: Microkernel oder Monolithischer Kernel  (Gelesen 24186 mal)

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« am: 26. September 2005, 18:23 »
Hi,

ich wollte eigentlich ein Konzept für LOST schreiben, allerdings müsste ich dazu wissen, welcher der beiden Kerneltypen bevorzugt wird.
Also ich hab mir bis jetzt ziehmlich viele Gedanken zu einem modularisierten monolithischen Kernel gemacht und wäre deshalb dafür.

Wenn ich ne umfrage machen könnte, würde ich eine machen.
Wie steht ihr dazu oder ist es euch eigentlich egal und ich soll mal machen?

MfG
DDR-RAM


[/html]

Dingsi

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 26. September 2005, 18:39 »
modularisierten Microkernel << Gibts auch einen nicht-modularisierten Microkernel? ^^ Ich mein.. die Modularität ist doch fest im Prinzip eines Microkernels verstrickt, oder?

Mmh, (modularer) monolithischer Kernel wäre am einfachsten, oder? Ich wär eigentlich dafür.
Auch wenn der Microkernel vielleicht die Zukunft ist, ich denke ein OS zum Lernen sollte ersteinmal die einfachsten Konzepte vorstellen.

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 26. September 2005, 19:29 »
waren schreibfehler meinerseits, hab es geändert, damit haben wir die gleiche Meinung :D

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #3 am: 26. September 2005, 19:55 »
Hmm, ich hatte in Zukunft erstmal vor, Modularität zu implementieren, jedoch dabei noch nicht den Kerneltyp u.ä. komplett festzulegen.
Ich denke an der Stelle eine planungstechnische Trennung zu machen könnte manches sauberer halten wenn man es richtig macht! ;)
Falls es jemanden interessiert! ;)
*post*

stultus

  • Beiträge: 486
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 26. September 2005, 20:07 »
ich würd nach wie vor nen microkernel bevorzugen, der ist kleiner, evtl. schneller und vorallem stabiler
MSN: planetconquestdm@hotmail.de
ICQ: 190-084-185

... Wayne?

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 26. September 2005, 20:08 »
Intressieren tut es.
Natürlich kann man versuchen solange wie möglich versuchen den Kerneltyp auszuklammern, aber ich denke es wird noch sauberer, wenn er von vornherein feststeht, damit nicht immer irgendwie aktuell was zusammengeschustert wird, sondern das schon am Anfang ein gutes Konzept gibt, das dann umgesetzt wird.

Roshl

  • Beiträge: 1 128
    • Profil anzeigen
    • http://www.lowlevel.net.tc
Gespeichert
« Antwort #6 am: 26. September 2005, 20:10 »
Also eigentlich ist ein Monokernel schneller, da weniger Kontextwechsel vorgenommen werden müssen^^
[schild=1]Wieder ein wertvoller(?) Beitrag von Roshl[/schild]

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 26. September 2005, 20:34 »
Hm, also schneller ist ein "Monokernel", wie Roshl sagt, in den meisten Fällen. Ob es interessant ist, ob der Kernel kleiner ist, ist fragwürdig, außer man möchte einen Rekord aufstellen.
Die Frage der Stabilität ist natürlich nicht außer Acht zulassen.
Ein guter Mikrokernel wird wahrscheinlich immer stabiler sein, als ein mittelmäßiger Monolithischer.
Aber ein modularisierter monolithscher Kernel kann auch stabil sein.
Denn wenn in einem Treiber ein Fehler auftritt, kann er doch genau wie beim Microkernel einfach neugeladen werden.
Man muss nur seine Standardrechte beschneiden, so das er z.B. nicht wahlfrei den virtuellen adressraum des Kernels überschreiben kann, sondern für einen bestimmten Speicherbereich schreibrechte anfordern muss, falls er sie benötigt. (in seinem eigenen Adressraum natürlich nicht).
Und durch die Modularität kann er genauso dynamisch, wie ein Mikrokernel sein. (bei entsprechender Implementation)

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #8 am: 26. September 2005, 21:35 »
Damit machst du grad wieder einen Microkernel, zwar nicht so extrem wie L4, aber der Begriff ist eh nur schwammig definiert.
*post*

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 26. September 2005, 21:58 »
Naja,
dann sollten wir das doch so machen, dann haben wir stabilität und geschwindigkeit vereint :D
Aber ein Microkernel ist für mich ein Kernel bei dem so wenig, wie möglich im Kernel abläuft bzw. nur ein kleiner Teil des Codes mit Ring0-Privilegien hat, diese will ich den Treibern ja nicht absprechen, sondern sie nur in ihrem virtuellen Adressraum einengen. Das ist ja ein Unterschied. Wenn ein Treiber also absichtlich bösartig ist, sollte bei meinem Modell nicht schwer sein. Bei einem Microkernel, sollte ein Treiber und sei er noch so bösartig nicht das system lahmlegen können, so meine Interpretation von Microkernel. Aber ich denke ich schreibe einfach mal ein Konzept und präsentiere es irgendwann und wer gewillt ist sich das alles durchzulesen, der kann dann Verbesserungsvorschläge bzw. Erweiterungsvorschläge etc. einbringen oder selbst ein eigenes erstellen.

MfG
DDR-RAM

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #10 am: 26. September 2005, 23:04 »
Ich denke auch das wenn man nicht jeden Mist auf nur irgendwelchen Umwegen per Verrenkung ins Userland befördern will man durchaus in den Bereich zwischen Linux und L4/Linux kommen könnte, also von der Diskussion Geschwindigkeit/Typ.
*post*

Osbios

  • Beiträge: 247
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 17. January 2006, 17:36 »
Mein Vorschlag ist ein Microkernel der NUR Basiselemente enthält. Das heißt für mich Prozessor-, Speicher-, IO-Port, IRQ, und Timingverwaltung. Alles andere läuft im Usermode!

Das heißt: alle Port Ein-/Ausgaben würden über Kernelfunktionen stattfinden.
Ein Treiber kann das System nicht zum Abstürzen bringen!

Das ist eventuell nicht so schnell, aber speziel für ein com-os deshalb geeignet weil die Grundlagen auf sehr wenige Komponenten reduziert werden, und die Entwicklung dann hoffentlich wieder vorwärts/weiter geht.
db 0x55AA

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 17. January 2006, 22:23 »
Zitat von: Osbios
Mein Vorschlag ist ein Microkernel der NUR Basiselemente enthält.

Ok, ein Mikrokernel enthält per Definition nur Basiselemente 8).

Zitat von: Osbios
Ein Treiber kann das System nicht zum Abstürzen bringen!

Leider ist das nicht so einfach getan. Beispiel: ein Treiber überträgt Daten per DMA vom Gerät in den Hauptspeicher, dabei kann er jegliche physische Addresse angeben und alles im Hauptspeicher überschreiben. Das ist natürlich blöd, weil dann jeder Treiber böse Dinge tun kann (ISA DMA könnte man noch gut Kontrollieren, aber bei PCI DMA sieht das glaub ich anders aus). Also braucht man vertrauenswürdige Userland-Treiber oder man holt die Treiber in den Kern (selbstgeschriebenes ist vertrauenswürdig) -> dadurch würde man das Mikrokernel-Konzept wieder leicht auflösen :?.
Agieren statt Konsumieren!

SSJ7Gohan

  • Beiträge: 398
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 17. January 2006, 22:29 »
Der Ansatz des Microkernels verhindert ja keine bösartigen Treiber. Er verhindert nur, das das System durch Programmierfehler abstürzt.

Ein HDD Treiber kann z.B. den MBR überschreiben und eigene Codestücke reinschreiben. Zum abstürtzen können die Treiber das System nicht mehr so leicht bringen, aber indirekt zerstören können sie es. Wenn man sie jedoch in den Kernelmode verlegt, können sie das ganze System wegen einem Bufferoverflow (die aber in Treiber eigentlich nicht sein sollten o.o) abstürzen lassen.

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 17. January 2006, 22:34 »
Ja, wollt ja nur die Aussage relativieren, hast schon recht. :D
Agieren statt Konsumieren!

Osbios

  • Beiträge: 247
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 18. January 2006, 17:42 »
Wie ihr sagt, es können die meisten Fehler verhindert werden. Und einen sog. bösartigen Treiber wird man sowieso nicht bändigen können.

Es ging mir dabei aber darum so viel wie möglich aus dem Kernel zu nehmen um die entwicklung voranzutreiben. Ich würde empfehlen, dass der Kernel NUR eine API für direkte Kernelfunktionen bereitstellt. Alle anderen APIs würden ganz einfach über IPC von den Modulen gestellt.
db 0x55AA

SSJ7Gohan

  • Beiträge: 398
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 18. January 2006, 17:58 »
Allgemein ist ein Monolitischer Kernel einfacher als ein Microkernel.
Ein Monolitischer Kernel kann auch klein sein. Er muss eigentlich nur Speicher und Prozessmanagement enthalten (naja, Prozessmanagement eigentlich nicht, das kann auch in Module), der Rest kann in Module ausgelagert werden. Beim Microkernel sind die Treiber ja Prozesse, deshalb braucht der Kernel noch IPC Funktionen. Ausserdem werden die Treiber komplexer, weil sie miteinander kommunizieren müssen.

 

Einloggen