Lowlevel

Lowlevel => OS-Design => Thema gestartet von: FreakyPenguin am 19. September 2006, 21:36

Titel: YoctOS - Designfragen
Beitrag 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
Titel: YoctOS - Designfragen
Beitrag von: T0ast3r am 20. September 2006, 17:53
Zitat
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.

Zitat
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
Titel: YoctOS - Designfragen
Beitrag von: FreakyPenguin am 20. September 2006, 18:00
Zitat von: T0ast3r
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.
Titel: YoctOS - Designfragen
Beitrag von: MNemo am 20. September 2006, 18:10
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.
Titel: YoctOS - Designfragen
Beitrag von: T0ast3r am 20. September 2006, 18:24
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)
Titel: YoctOS - Designfragen
Beitrag von: bluecode am 21. September 2006, 01:51
Zitat von: T0ast3r
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).
Titel: YoctOS - Designfragen
Beitrag von: Legend am 21. September 2006, 08:45
Zitat von: togi
Zitat von: T0ast3r
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!!! ;)
Titel: YoctOS - Designfragen
Beitrag von: FreakyPenguin am 21. September 2006, 17:07
Zitat von: T0ast3r
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.

Zitat von: T0ast3r

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


Zitat von: Legend
Jo, und ich hoffe du meinst damit dann ne Permission Bitmap. Für jeden einzelnen Zugriff nen Systemaufruf ist schonmal sicher - arghs!!! Winken

Jep
Titel: YoctOS - Designfragen
Beitrag von: bluecode am 21. September 2006, 17:41
Zitat von: togi
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
Titel: YoctOS - Designfragen
Beitrag von: FreakyPenguin am 21. September 2006, 19:18
Zitat von: bluecode

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.
Titel: YoctOS - Designfragen
Beitrag von: bluecode am 22. September 2006, 04:36
Das musst du eben nicht. :wink:
Titel: YoctOS - Designfragen
Beitrag von: Legend am 22. September 2006, 09:04
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.
Titel: YoctOS - Designfragen
Beitrag von: T0ast3r am 22. September 2006, 18:55
Zitat von: Legend
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.
Titel: Re: YoctOS - Designfragen
Beitrag von: Legend am 23. September 2006, 15:55
Na ja, der Code der die Bitmap bearbeitet, den muss er natürlich selber schreiben.