Thema: Kernel-Entwurf

[mastermesh]

Jeder, der meint, einen guten Entwurf für den Kernel des Comm-OSes zu haben, schreibt bitte diesen hier herein. Am besten gegliedert nach den folgenden Kategorien: Allgemeiner Kernel-Typ, API, Treiber, Memory Management, Prozess-Modell, IPC

[joachim_neu]

Na dann, hier mein Kernelvorschlag.

Kernel-Typ:
Mikrokernel mit Grundapifunktionen (Task starten, Task beenden, IPC anfordern). Ebenso Grundlagentreiber wie FDD und HDD im Mikrokernel und einen Treiber für VESA.
API:
Kann von jedem Programm nachgeladen werden, wie DLLs, und wird in den virtuellen Speicher des Programmes geladen. Da ist es dann benutzbar als währe es Teil des Programmes, sprich wie programmeigene Funktionen.
Treiber:
Werden je nach Typ (Hardware, Software) entweder als Tasks geladen (Hardware) und durch IPC gesteuert oder als API-Teil geladen (Software) und vom Programm benutzt. Hardware ist alles, was mit Ports zu tun hat, Software sind zum Beispiel FileSystemTreiber.
Memory Management:
Arbeiten mit Paging, jeder Task hat seinen virtuellen Bereich, wo der Kernel für API-Calls rein gemappt ist und jeder Task kann sich holen, was er braucht. Die Zugriffe werden über eine Exception abgefangen und der Task erhält dann den Speicher ohne vorheriges Allocieren. Möglich ist auch der Einbau eines malloc()-Funktion, die jedoch dann immer benutzt werden muss, allerdings auch nur Zugriffsadressen zurückgibt, auf die das Programm dann zugreift. Es ist also eine Kombination, jedoch kann man während der Laufzeit nicht beide Teile kombinieren, da es sonst zu Schwierigkeiten kommt.
Prozessmodell:
Nachdem mich mastermesh aufgeklärt hat, was das is schreib ich das hier. Als Prozessmodell würde es nur Tasks geben. Die könnten gerne auch andere Teile in ihren Space laden und mit denen Thread spielen oder sonstwas, aber dazu müssten diese Teile mit anderen Orgin-Werten kompiliert werden, also darauf speziel getrimmt sein und vom "Vater" geladen werden.
IPC:
Die Prozesse kommunizieren mit hilfe von Briefkästen und können einen Speichertransfer anfordern, der aber von dem anderen Prozess bestätigt werden muss.

J!N

EDIT: Prozessmodell

[DDR-RAM]

Ich sag einfach mal paar Sachen, womit ich mich in letzter Zeit beschäftigt habe.

KernelTyp:
MicroKernel mit MemoryManager, ProzessManager, UserManager, Abstraktionsschicht, evtl. Treiber für Laufwerke.
Der Rest kommt in einzelne Module.

Treiber:
So wie joachim_neu

Speicherverwaltung:
Der Kernel sollte im logischen Speicher, nen Addressraum für nen Heap haben, z.B. von 0xD0000000 bis 0xE0000000.
Den MemoryManager würde ich so machen, er besteht aus Knoten, der erste ist z.B. bei 0xD0000000 und geht am Anfang bis 0xE0000000, der Speicher muss ja nur im Page Dir reserviert sein. Bei Zugriff mit malloc wird nen Freier Block gesucht, über nen Avl-Baum, falls der Block zu groß ist, wird er gesplittet. Vielleicht bisschen kurz die Erklärung, hab das bis jetzt aber nur mit C++ implementiert, funktioniert auch einwandfrei, habe da noch paar weitere Sachen drinne für kleine Blöcke und so.
Für Usermode-Programme sollte das so ablaufen, das es sone Art VirtualAlloc gibt, und der Speicher dann bei Bedarf alloziert wird. Außerdem malloc/free/realloc in ne Dll rein und ähnlich implementieren, wie für den Kernel.

Prozessverwaltung:
Da wäre ich z.B. dafür, dass man zwischen mehreren Scheduler-Typen wählen kann, außerdem Multithreading.
Jeder Prozess hätte dann mindestens einen Thread.
Die Threads sollten auf TSS-Basis sein, im TSS könnte man auch floating-point Unit speichern und weitere Informationen.

IPC:
ReadProcessMemory, WriteProcessMemory mit entsprechender Rechtevergabe, gemeinsame Speicherbereiche, Messaging, Events, Mutexes, Semaphores, halt alles was dazu gehört.
Den Kernel würde ich möglichst pre-emptiv halten.

Allgemein:
Also ich würde nach außen hin, alle Möglichkeiten, die ein Unix oder Winprogramm braucht diesem auch native zur Verfügung stellen.
Man muss nur gut Abstrahieren.

evtl. kommt noch was.

MfG
DDR-RAM

[T0ast3r]

Ich möcht meinen Senf auch noch dazugeben:
Ich würde nicht eine Microkernel (also wo alles in einer Datei ist) machen, sondern je nach Kategorie das ganze aus Dateien laden.
So lassen sich Fehler viel leichter heraussuchen, und das System läuft stabiler.
Denn wenn ein Modul (z. B. ein einzelner Treiber) abstürzt, betrifft das nur das eine Modul.
zudem kann man so schöne Updates einspielen, da nur je Modul eine Datei ersetzt werden muss.
Ich würde eben eine flexible lösung bevorzugen.
einen Entwurf wie jn arbeite ich gerade aus.
Ich stelle ihn dann mögichst bald ins Netz.

[DDR-RAM]

Ich möcht meinen Senf auch noch dazugeben:
Ich würde nicht eine Microkernel (also wo alles in einer Datei ist) machen, sondern je nach Kategorie das ganze aus Dateien laden.

Entweder ich hab jetzt was falsch verstanden oder du, Microkernel enthält nur das nötigste und der Rest kommt in ausgelagerte Module.
Du meintest wohl, das du keinen monolithischen Kernel willst.

aber trotzdem ACK

MfG
DDR-RAM

[T0ast3r]

Upps, da hab ich was nicht so verstanden.
Danke dass du mir's gemeldet hast.
Aber was nun ein Microkernel so ist, ich mein das was ich geschrieben hab, also alles auslagern.

[T0ast3r]

Nun möchte ich noch meinen Senf zur API abgeben:
Die Programme benützen ja die API um Librarys nachztuladen.
Deswegen würde ich immer vor jedem Programm eine Tabelle anlegen, wo der Speicherort der "GrundBlibliothek" ist.
Von der kann man dann andere laden und so.
Oder man gibt die Adr. häufig benutzende Librarys gleich in die Tabelle und der Benutzer kann sie dann gleich herauslesen.
Er übergibt der Library die Funkltionsnummer, und die Bearbeitet das dann in der gewünschten Funktion.