Lowlevel
Lowlevel => OS-Design => Thema gestartet von: jeb am 06. January 2006, 17:39
-
Hallo!
In der letzten Woche habe ich mich wieder mal verstärkt mit OS-Dev auseinandergesetzt. Zuerst hab ich mir das mit dem Kernel überlegt, Monlithisch oder Mikro. Aber da man beim Monlithischen Kernel ja auch immer den Kernel als Prozess aufrufen soll, sehe ich da keinen Vorteil in der Geschwindikeit (muss mir den PM nochmals genau ansehen). Auf jeden Fall hab ich jetzt eine vernünftige Lösung für das Multitasking mit Mikrokernel gefunden. Jetzt kommt eigentlich die Programmierschnittstelle, also die HAL (ist immer noch alles theoretisch. existiert noch kein code).
Wie macht man eine HAL (hardware abstraction layer)? Das Problem für mich, dass wenn ich neue Eigenschaften wie z.B. einen Grafiktreiber hinzufüge, dass dann die HAL anders aussieht und sie ja eigentlich auch Rückwärtskompatibel sein muss. D.h. der Code müsste immer noch an der gleichen Speicherstelle liegen.
Ich habe mir mal etwas in der Art überlegt, dass ich Indexes setzt für die jeweiligen Indexes und das dann so wie die Interrupts mache. D.h.: das Dateisystem wird immer über den Index 1 angesprochen. Mittels eines weiteren Indexes findet man dann die richtige Funktion. Jeder Index hat dann genau x Bytes zur Verfügung, um in den richtigen Selektor zu wählen. Dann wird dorthin gesprungen.
Zu den Treibern noch: Was findet ihr besser? einen GDT Eintrag für alle Treiber und darin eine LDT sowie das gleiche für die Programme? Oder für jeden einzeln einen Deskriptor und dann vermerken, ob es ein Treiber od. Programm ist?
mfg, jeb
-
Hi!
Mir ist gerade aufgefallen, dass in der neuen Ausgabe von Lowlevel ein Artikel über die HAL ist. Den les ich mir jetzt gerade durch. Vieleicht könnt ihr mir aber trotzdem auf meine Fragen antworten.
mfg, jeb
-
Und mein dritter Post :wink: Zum Anfang grad mal ein Zitat aus lowlevel_8:
3. Was kommt ins HAL?
Die einzige sinnvolle Antwort auf diese Frage ist: Alles was du für hardwarenah hältst. Damit aber nicht der komplette Kernel im HAL landet, habe ich versucht einige wichtige Sachen aufzuzählen:
* Port-Zugriffe
* Direkte Zugriffe auf die Register
* Viele Macros (Größe eines Words, Größe einer Page, ...)
* Interrupts, Exceptions, IDT/IVT, ...
Interrupts sind in Bezug auf Portieren eine echt üble Sache. Man sollte also so schnell wie möglich versuchen, sie in etwas anderes âumzuwandelnâ (z.B. Popup-Threads)
Und noch eins:
Wer seinen Kernel früher oder später auf andere Platformen/Architekturen portieren will, muss im schlimmsten Fall den kompletten Kernel umschreiben. Um das so weit wie möglich zu verhindern, sind viele Kernel in ein HAL und den Rest aufgeteilt
Ist das nicht ein kompletter Wiederspruch? Ports, Interrupts und Register! Die sind ja auf jeder Archidektur anders, sollten sich also hinter der HAL verstecken, als das sie in die HAL integriert sind? Da kann man nacher ja trotzdem wieder die ganze HAL neu schreiben :? Entweder hab ich da was flasch verstanden, oder das Prinzip der HAL nicht richtig begriffen. Ich möchte euch deshalb bitten, meinen ersten Post nochmals zu lesen und mir sagen, was ihr davon haltet. Um sich eine eigene Meinung zu bilden muss man ja noch keine HAL gemacht haben.
mfg, jeb
-
Ja, besser den HAL neu schreiben, als alle Treiber usw.
-
Ich versteh unter einem/einer (wie heißt das??) HAL sowas:
--------------
| KERNEL |
--------------
|
V
--------------
| HAL |
--------------
Das heißt, dass das HAL eine Art Bibliothek ist, die alle Systemrelevanten Funktionen beeinhaltet. Der Kernel greift nur über diese Funktionen auf die Hardware zu.
Zu deinem ersten Post: Ehrlich gesagt versteh ich den nicht ganz ;) Wenn du willst kann ich hier aber mal etwas Code posten, um zu zeigen, wie ich das bei mir umgesetzt hab.
-
Sieht so aus, als habe ich das Prinzip der HAL falsch verstanden. Ich habe es so aufgefasst:
Die HAL bietet eine Abstraktion. Wenn man Programme schreibt, die nur auf die HAL zugreifen, dann kann der Code ohne Ãnderungen auf einer angepassten HAL auf einer anderen Archidektur verwendet werden.
Da jedoch die andere Archidektur die Ports anders verteilt, ist das ja nicht möglich. Z.B. ein Tastaturtreiber der über die HAL auf Port 16 zugreift (stimmt nicht, aber egal), den kann man auf der neuen Archidektur nicht einfach nochmals kompilieren, da diese Archidektur für diese Aufgabe vielleicht gar keine Ports einsetzt :shock:
Das ist mein Problem.
mfg, jeb
-
Nun, der Tastaturcontroller-Chip von x86 Systemen wird ja auch auf anderen Systemen wahrscheinlich nicht eingesetzt, oder doch? ;)
In diesem Falle funktioniert es besser die Ansteuerung des Chips und das Parsen der Scancodes zu trennen. So braucht man den Code für verschiedene Codepages evtl. nur einmal zu programmieren.
-
Nun, der Tastaturcontroller-Chip von x86 Systemen wird ja auch auf anderen Systemen wahrscheinlich nicht eingesetzt, oder doch? ;)
Das ist gerade das, was ich unter einer HAL verstehe. Programme die die Tastatur brauchen müssen nur neu kompliliert werden, nicht neu geschrieben da der andere Controller innerhalb der HAL programmiert ist.
-
Userlevel Programme nutzen die Treiber und den Kernel, die Treiber und der Kernel nutzen das HAL.
So muss man nicht den Kernel für jede Architektur neu schreiben (oder zumindest kann man große Teile davon zwischen den Archtitekturen teilen (Scheduler usw.)), nur die Gerätetreiber (Filesystem Treiber z.B. nicht) und das HAL.
-
Zum Tastaturtreiber: Genau da liegt das Problem mit dem/der HAL! Gehört so etwas noch darein oder nicht? Im Prinzip ist es platformabhängig, aber man kann nicht jeden Treiber mit aufnehmen. Deshalb versucht man eine Art Basis zu erstellen, auf die die Treiber aufbauen können. Die Userprogramme können dann mit Hilfe dieser Treiber auf die Hardware zugreifen und verwenden dabei indirekt das HAL.
Zur Implementierung:
Anhand des Beispiels Multitasking erklär ich, was ich davon ins HAL aufgenommen hab. In dem Headerfile hal_main.h definiere ich alle Funktionen, die das HAL bereitstellt. Die Funktionen die Multitasking betreffen sind hauptsächlich zwei: pre_schedule und post_schedule. pre_schedule wird vor dem eigentlichen Scheduler aufgerufen (pusht register auf den Stack), post_schedule nach dem Schedulen (pop Register, wechselt Task). Der eigentliche Schedulingalgorithmus liegt allerding im normalen Kernel.
Wenn ich jetzt den Kernel auf eine neue Platform portiere, muss ich nur pre_schedule und post_schedule neu schreiben, die nur einen Bruchteil des Multitasking-Codes darstellen. Der Rest kann 1 zu 1 übernommen werden.