Thema: Micokernel - Designidee

[jeb]

Hallo OS-Devers!

Einige kennen mich vielleicht noch. Ich habe mich nach langer Pause wieder dazu entschieden, mich mit der Betriebssystemprogrammierung auseinanderzusetzen. Mit zwei anderen diskutiere ich gerade, wie dieses Umgesetzt werden will. Ich habe in meinem Gedächtnis gekramt um meine alten Ideen wieder hervorzuholen. Was mir noch in den Sinn kam, habe ich jetzt in einem Abend aufgeschrieben. Es ist wahrscheinlich noch nicht so gut formuliert und wahrscheinlich auch noch nicht so technisch. Das liegt vorallem daran, dass ich mich schon lange nicht mehr mit dem Thema beschäftigt habe und der Text vorallem dazu dient, die andere von meiner Idee zu überzeugen.
Mich würde es jetzt nun interessieren, was ich vom Konzept haltet und wo ihr Nachteile von Vorteile im Design seht. Ihr findet den Text unter: http://bin.jebdev.net/os.txt

Vielen Dank für eure Rückmeldungen

jeb

[bluecode]

Willkommen zurück

Ich würde einen Microkernel schon für ein bisschen mehr als die Speicherverwaltung benutzten (die übrigens in mehreren existierenden OS bereits aus dem Kernel ausgelagert wurde, d.h. nicht essentiel für den Kernel). Eigentlich ist die Prozessverwaltung und die Annahme von syscalls (v.a. für IPC) die Kernaufgabe eines Microkernels. Das Problem bei deinem Design ist, dass du genau das in deinen Ressource Loader abschiebst.
Ich würd also das Ausführen (nicht das Laden!) von elf/<your favorite executable file format> sowie die Prozessverwaltung in den Kernel verschieben. Deinen Ressource Loader würd ich nur dazu benutzen die ersten/wichtigesten Module zu laden (bei mir ist das init, der treiber des Speichermediums, das vfs und der Dateisystemtreiber, welche von grub geladen werden und anschließend vom kernel ausgeführt werden) und die Adressen/Größe an den Kernel übergeben, der wenn er mit der Initialisierung seiner selbst fertig ist, diese Module ausführt.

Falls du dir meinen Kernel mal ansehen willst, dann schau mal in meine Signatur...

[jeb]

Hi!

Danke für deine Rückmeldung. Was ich im Text noch nicht erwähnt hatte ist, dass ich vorhabe, das ganze Multitasking in den Kernel zu integrieren.
Wie meinst du das, das Ausführen dem Kernel zu überlassen, das Laden jedoch dem RL? Und sollte jetzt deiner Meinung nach diese Modultabelle vom RL oder vom Kernel verwaltet werden? Mit der Prozessverwaltung hast du Recht. Da hab ich gar nicht mehr so klar daran gedacht. Das werde ich wohl noch einmal überarbeiten.

Vielen Dank,

jeb

[MNemo]

was macht den ein Kernel aus?

Ich hätte jetzt dein RL Kenel genannt.
und dein Kernel ein Modul für die Speicher verwaltung.
(Bitte nicht hauen wenn das föllig daneben ist. )

--
sonst finde ich dein Design ganz o.k.

[bluecode]

Wie meinst du das, das Ausführen dem Kernel zu überlassen, das Laden jedoch dem RL?

Also (muss ein bisschen weiter ausholen ): Bei mir ist es so das ich einen Prozess generell in 2 Kategorien einteil: Server und normaler Prozess. Dem Server stehen ein paar erweiterte syscalls zu als den normalen Prozessen. Unter anderem eben auch ein syscall, mit welchem man aus einer in den Speicher geladenen Elf-Datei einen neuen Prozess erzeugt. Momentan ist es dann so, dass jede Anwendung eine anfrage an ein Dateisystem schicken kann, eine bestimmte datei auszuführen. Das Dateisystem lädt dann die Datei und ruft den kernel syscall auf. Das eine Anwendung nicht direkt den syscall ausführen kann soll die sicherheit ein wenig erhöhen...

Und sollte jetzt deiner Meinung nach diese Modultabelle vom RL oder vom Kernel verwaltet werden?

Ich würde sowas im Kernel verwalten.

[jeb]

Ok, mir ist jetzt bewusst geworden, dass ich die einen oder anderen Dinge nochmal genauer anschauen muss. Ich werde mich zuerst wieder ins Thema einlesen, und dann mein Design nochmals überarbeiten.
M.Nemo: Irgendwo hast du Recht.
Ich würde mal sagen ich habe diesen "Tick", alles unabhänig machen zu wollen. Meine Grundüberlegung für dieses Design war eigentlich, dass ich auf keinen Fall einen FS-Treiber im Kernel haben wollte. Denn wenn ich ein FS habe, dann müssen auch die anderen rein und das ist dann schlussendlich kein Mikrokernel mehr, meiner Meinung nach. Deshalb hab ich den Ressource-Lader erfunden. Das werde ich bestimmt nochmal überarbeiten. Das andere Problem ist die Tabelle. Ich muss mir diese nochmals neu überlegen. Denn wenn ich diese Tabelle zu genau definiere, so muss der Kernel über jedes neue, mögliche Modul bescheid wissen, was dann ja auch nicht mehr wirklich Mikrokernel ist, oder habe ich da ein falsches Verständnis von Mikrokernel?
Mich würde es jetzt noch interessieren, was ihr Grundsätzlich von der HAL-Tabelle haltet. Findet ihr diese so sinnvoll?

Vielen Dank,

jeb

[maumo]

also ein mikrokernel ist, soweit ich weiss ein kernel, der sich nur um prozess- und speichermanagement kümmert, und der seine treiber im user level, also wie ganz normale programme laufen lässt. das was du beschrieben hast klingt mir eher nach einem modularen monolithischen kernel, denn die treiber werden ja trotzdem alle an den kernel gelinkt und laufen nicht als einzelne prozesse.

[jeb]

Hm jetzt bekomme ich langsam ein Durcheinander. Im Text habe ich nichts davon geschrieben. Ich wollte das ja eben verhindern, indem ich den RL erfunden habe. Weil mir Bluecode jedoch dazu geraten hat, die Tabelle in den Kernel zu nehmen habe ich das so erwähnt. Wie wird denn das sonst bei Mikrokerneln umgesetzt (bin grad am googeln). Denn ein Programm kann ja nicht selbst dafür sorgen, dass alle Librarys und Treiber geladen sind, die es braucht (eben dazu den RL).

[maumo]

also bei mir z.b. (^^) macht das grub, der läd halt n festplatten n dateisystem und n init modul und den kernel diese werden dann vom kernel zu prozessen gemacht und worauf der kernel dann den initprozess startet, der wiederum auf die festplatte zugreift und von dort aus ein skript läd, in dem steht, welche treibermodule als nächstes zu laden sind. die kommunikation läuft über message passing, das wiederum über syscalls und dann über den kernel

[bluecode]

Weil mir Bluecode jedoch dazu geraten hat, die Tabelle in den Kernel zu nehmen habe ich das so erwähnt

Sry, war ein Fehler meinerseits. Die Erinnerung an deinen Text war schon ein bisschen verblast... Also ich würd das in der Form außerhalb des Kernels machen: In einem DeviceManager oä, bei dem sich dann zB jeder Bustreiber (pci, usb, p&p isa) melden kann, ob für Hardware XY ein Treiber vorhanden ist.
Ich denke das man für die libs keinen speziellen Mechanismus braucht.. soweit ich weiß sucht windows da auch nur in den standardverzeichnissen und in dem momentanen Arbeitsverzeichnis...

[jeb]

Also ich bin jetzt gerade daran, meine Idee zu überarbeiten. Dabei bin ich auf ein Problem gestossen: Hardware Interrupts. Wie werden diese im PM verarbeitet? Das muss doch irgendwie über die IDT gehen. Gibt es da reservierte Einträge?
Mein Problem mit den Hardware Interrupts ist, dass der Kernel eigentlich nix mit denen zu tun hat. Der Kernel weiss jedoch auch nicht, welcher Prozess dafür verantwortlich ist. Wie soll er darauf reagieren? Ich habe mich bisher noch nie mit dem Kommunikation von Geräten im PM auseinandergesetzt. Kann der Kernel diese einfach ingnorieren und sind die Informationen auch Softwaremässig wieder abrufbar, sodass der zuständige Server die Interruptinformationen nicht benötigt?

[bluecode]

Jeder Treiber registriert wenn er Lust hat einen IRQ. Wenn der Auftritt wird dem Treiber eine "message" (oder irgendeine andere Art der IPC) geschickt.

[jeb]

Also du meinst, jeder Treiber kann sich sozusagen in ein Newsletter eintragen. Wenn dieser Interrupt kommt, wird ihm einfach eine Nachricht geschickt? Das würde eigentlich auch keine Probleme machen, wenn zwei Treiber für den Interrupt existieren.

EDIT: Noch zur Treibertabelle:
Ich hatte zwei Ideen:
1.) Der Kernel führt eine Liste. Jeder Treiber kann sich mit einer ID in diese Liste eintragen. Der Kernel selbst weiss nicht, was das bedeutet. Wenn ein Programm gestartet wird schaut es, ob die entsprechende ID geladen ist. Man könnte diese IDs dann frei definieren. Man könnte ev. beim Systemstart diese Tabelle auch mit allen Treibern füllen und vermerken, ob er geladen ist oder nicht. Das ganze ist dann völlig unabhänig davon, was der Treiber beinhaltet, es ist jedoch alles zentral vom Kernel geregelt. Die Idee ist dann, dass z.B. alle Grafiktreiber sich mit der gleichen ID eintragen.

2.) Es gibt einen Treiber, der diese Aufgabe übernimmt. Dieser könnte dann aber die Gruppen auch genauer definieren.

Was haltet ihr davon?

[bluecode]

Ich wär wie gesagt für 2tens. Die Tabelle bei 1stens nützt dir ja nicht viel, wenn zB der PCI treiber festgestellt hat dass ein Gerät mit der HerstellerID 0x8086 und der GeräteID 0xXYZQ gefunden hat...
btw. zu wissen _ob_ ein Treiber läuft hilft meistens nicht viel. Du musst auch wissen wie du den Treiber (über IPC) ansprichst. Ansonsten ist der Treiber nutzlos.