Lowlevel
Lowlevel => OS-Design => Thema gestartet von: FreakyPenguin am 19. September 2006, 21:36
-
Hallo Zusammen
Ich ahb mich in letzter zeit wieder ein wenig mehr mit OS-Dev beschäftigt und beschlossen bei meinem OS von vorne zu beginnen, aufgrund schwerer Designfehler. Nuch habe ich mir aber diesmal vorgenommen, nicht wie wild drauf los zu coden, sondern zuerst einigermassen ein konzept zu entwerfen.
Ich hätte gerne mal einen kommentar, was ihr so von meinem Konzept haltet.
Im moment arbeite ich vorallem an der Speicherverwaltung.
Könntet ihr mir mail ein paar Kommentare dazu abgeben ?
Link: http://famkaufmann.info/~toni/wiki/index.php/YoctOS
Vielen Dank
MfG Togi
-
Wie schon im Vorspann erwähnt, ist es nicht mein Ziel irgend ein Revolutionäres Betriebssytem zu entwickeln, welches alle heutigen [...]
irgendein schreibt man zusammen :wink:
hmm ansonten gut dass du dir das Konzept vorher überlegt hast
den Kernel würde ich aber noch weiter spezifieren, in deinem Fall also ein Microkernel.
Dabei werden die Treiber(Server) im Benutzermodus und nicht im Systemmodus Laufen
Ich würde die Treiber eher als Clients ansehen, und alle Treiber mit PL3 laufen zu lassen ist (zumindest teilweise) nicht sinnvoll.
Man schützt das System nicht vor sich selbst.
Ich würde eher zwischen lowlevel und highlevel Treiber/Clients unterscheiden.
Oder das beste (aber eher schwierig zu handlen) wäre nur die jeweiligen benötigten Ports/(andere I/O Dinge) freizugeben, wie es per TSS und IOPL bzw. auch per Permission Bits machbar ist.
lg,
Toaster
-
Ich würde die Treiber eher als Clients ansehen, und alle Treiber mit PL3 laufen zu lassen ist (zumindest teilweise) nicht sinnvoll.
Man schützt das System nicht vor sich selbst.
Ich würde eher zwischen lowlevel und highlevel Treiber/Clients unterscheiden.
Oder das beste (aber eher schwierig zu handlen) wäre nur die jeweiligen benötigten Ports/(andere I/O Dinge) freizugeben, wie es per TSS und IOPL bzw. auch per Permission Bits machbar ist.
Ich denk grad drüber nach, den Zugriff auf die Ports nicht direkt zu gestatten, sondern nur über API(um die Ports einzeln verwalten zu können).
Ncoh ne andere Frage: Ist es möglich, den Kern irgendwie vom DMAC zu "schützen" ?
Ich mein, damit nicht irgendein (:lol:) Treiber (ob absichtlich oder nicht) telie des Kernel überschreibt.
-
Der DMAC kann glaub ich nur auf die ersten 16MB zugreifen. D.h. du müstest den(/das?) Kernel einfach weiter oben platzieren. Sonst glaub ich kann man da nix vor schützen.
-
wenn du Paging verwendest solltest du im vorhinein definieren was der Kernel memory ist. (normalerweise die oberen 2 GB oder 1 GB)
die Ports per API zu verwalten/zu verwenden ist nicht sehr effektiv, per I/O Permission Bitmap im TSS kann man eh bestimmte Ports freigeben, ich sehe da also kein Problem
und du solltest ev. im auch schon Handles/IDs definieren, die Tasks und Prozesse usw. bekommen (und Task/Prozess Objekt definieren)
-
wenn du Paging verwendest solltest du im vorhinein definieren was der Kernel memory ist. (normalerweise die oberen 2 GB oder 1 GB)
Falls du das im Zusammenhang mit dem DMA Controller meintest: Der DMA Controller hat Zugriff auf den physikalischen, nicht den virtuellen RAM ;)
Schutz davor: Nur bestimmten Port Zugriff erlauben und den Kernel den DMA Controller verwalten lassen.
I/O Permission bitmap ist nicht sonderlich portabel (wenn das für jemanden ein Kriterium ist).
-
Ich würde die Treiber eher als Clients ansehen, und alle Treiber mit PL3 laufen zu lassen ist (zumindest teilweise) nicht sinnvoll.
Man schützt das System nicht vor sich selbst.
Ich würde eher zwischen lowlevel und highlevel Treiber/Clients unterscheiden.
Oder das beste (aber eher schwierig zu handlen) wäre nur die jeweiligen benötigten Ports/(andere I/O Dinge) freizugeben, wie es per TSS und IOPL bzw. auch per Permission Bits machbar ist.
Ich denk grad drüber nach, den Zugriff auf die Ports nicht direkt zu gestatten, sondern nur über API(um die Ports einzeln verwalten zu können).
Jo, und ich hoffe du meinst damit dann ne Permission Bitmap. Für jeden einzelnen Zugriff nen Systemaufruf ist schonmal sicher - arghs!!! ;)
-
wenn du Paging verwendest solltest du im vorhinein definieren was der Kernel memory ist. (normalerweise die oberen 2 GB oder 1 GB)
Hab ich so geplant.
die Ports per API zu verwalten/zu verwenden ist nicht sehr effektiv, per I/O Permission Bitmap im TSS kann man eh bestimmte Ports freigeben, ich sehe da also kein Problem
Objekt definieren)
Ich verwende Software Multitasking also entfällt die möglichkeit mit der I/O Permission Bitmap im TSS, darum werde ich das per Software lösen
Jo, und ich hoffe du meinst damit dann ne Permission Bitmap. Für jeden einzelnen Zugriff nen Systemaufruf ist schonmal sicher - arghs!!! Winken
Jep
-
Ich verwende Software Multitasking also entfällt die möglichkeit mit der I/O Permission Bitmap im TSS, darum werde ich das per Software lösen
Fürs Software Multitasking brauchst du auch ein TSS ;) Also muss diese Möglichkeit nicht unbedingt entfallen
-
Fürs Software Multitasking brauchst du auch ein TSS ;) Also muss diese Möglichkeit nicht unbedingt entfallen
Ja aber ich muss das ganze mit den Berechtigungen selbst auf softwarebasis machn.
-
Das musst du eben nicht. :wink:
-
Abgesehen davon das du trotz Software Task Switching eine TSS einmal einrichten musst wenn du den Ring 3 benutzen willst, kannst du in dieser TSS auch die Bitmap reinsetzen. Die soll glücklicherweise auf Paging reagieren, d.h. mit guter Platzierung wechselt du mit dem Wechsel von CR3 auch die Bitmap aus.
-
Abgesehen davon das du trotz Software Task Switching eine TSS einmal einrichten musst wenn du den Ring 3 benutzen willst, kannst du in dieser TSS auch die Bitmap reinsetzen. Die soll glücklicherweise auf Paging reagieren, d.h. mit guter Platzierung wechselt du mit dem Wechsel von CR3 auch die Bitmap aus.
Ah, endlich einer der es auf den Punkt (mit der Richtigkeit) bringt.
Genauso siehts aus, man braucht ein TSS (man kann auch eins für alle Tasks nehmen), indem man auch eine Permission Bitmap reingeben kann, wenn das TSS sowieso existieren muss
Interessant wäre dann natürlich für bestimmte zwecke bestimmte TSSe zu haben, eins für allen normalen Tasks, eins für alle (wirklich) system nahen Tasks (Kernel) und eigene für Treiber.
-
Na ja, der Code der die Bitmap bearbeitet, den muss er natürlich selber schreiben.